Hi Jacopo,
Your solution is a good pragmatism and give a clear work to do for
contributors
If other people are ok with your proposition, I will try to find a
solution to activate a component with ant.
PS : My apologies for the latency
Nicolas
Le 07/01/2013 09:20, Jacopo Cappellato a
Thanks Nicolas.
I had a quick look too to find a way to exclude specialpurpose components from
the build/test process and the easiest way (I didn't test it) would be to set
the property:
specialpurpose.present to false.
At the moment it is set with:
available file=specialpurpose/build.xml
Of course in both cases we should cleanup and improve our ant scripts and
remove direct references to specific specialpurpose components like:
fileset dir=${ofbiz.home.dir}/specialpurpose/birt/lib
includes=*.jar/
fileset dir=${ofbiz.home.dir}/specialpurpose/ebaystore/lib
It's sound good, I just see a little problem if we want only one
specialpurpose component, we need to do
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
$ cd ofbiz-trunk
$ mkdir specialpurpose
$ cd specialpurpose
$ svn co
Yes, it makes a lot of sense to treat the specialpurpose components as
hot-deploy components.
However I'd suggest to move at small steps in this direction because right now
there are specialpurpose components that depends on each other and this would
make the story more complicated if you want
:) right, so change 13.04 by 14.04 on my last comments ;)
On my side, I will test OFBiz without specialpurpose to find bad depends.
Nicolas
Le 16/01/2013 16:21, Jacopo Cappellato a écrit :
Yes, it makes a lot of sense to treat the specialpurpose components as
hot-deploy components.
However
Very clear and efficient
Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
Let's see if we can move on the slim-down effort in this direction; here is a
slightly more detailed proposal:
* svn layout of the project will stay as is now:
framework+applications+specialpupose; if you checkout the
Let's see if we can move on the slim-down effort in this direction; here is a
slightly more detailed proposal:
* svn layout of the project will stay as is now:
framework+applications+specialpupose; if you checkout the trunk you will get
everything as it is now
* however all the specialpupose
I think this is a very good idea, Jacopo - straight forward and easy to
maintain
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4638733.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
A bit out of subject, I found this article interesting
http://kohsuke.org/2013/01/04/the-other-side-of-forking-and-pull-requests
And he made me wonder how the OpenErp project is handling its addons (some
years ago someone told me this was a weak part of the project, I never dug)
Jacques
From:
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
Let's see if we can move on the slim-down effort in this direction; here is a
slightly more detailed proposal:
* svn layout of the project will stay as is now:
framework+applications+specialpupose; if you checkout the trunk you will
From: d...@me.com
On Jan 5, 2013, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
From: Ean Schuessler e...@brainfood.com
I don't know that its much worse. On GitHub you will see the forks and
could track their changes if you wanted.
I think the complication with handing
Because it's possibly easier for committers to follow the work done and not get
a big patch at the end.
With Git you tend to receive either a burst of patches or a big one, both in
one shoot.
Then it's hard to review the work done. By steps it's easier
I don't use GitHub, I have enough to do
I don't know that its much worse. On GitHub you will see the forks and could
track their changes if you wanted. I think the complication with handing out
SVN branches is that we will end up with a lot of low quality branches in the
core repository. The nice thing about GIT is that the chaff
From: Ean Schuessler e...@brainfood.com
I don't know that its much worse. On GitHub you will see the forks and could
track their changes if you wanted.
I think the complication with handing out SVN branches is that we will end up
with a lot of low quality branches in the core repository.
On Jan 5, 2013, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
From: Ean Schuessler e...@brainfood.com
I don't know that its much worse. On GitHub you will see the forks and could
track their changes if you wanted.
I think the complication with handing out SVN branches is
I was reading this article and suddenly thought: why not giving access to
branches in OFBiz project to people who need more than a patch to submit in a
Jira (clearly Tom and I would have loved that)?
http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
Opinions?
Jacques
From:
One of the solutions is to create brach on github,
https://github.com/apache/ofbiz. A feature can be developed on Github and then
a final patch can be submitted to Ofbiz Jira.
Regards
Anil Patel
On Jan 4, 2013, at 9:17 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I was reading
Why wouldn't they just fork and then issue a pull request on GitHub?
- Jacques Le Roux wrote:
I was reading this article and suddenly thought: why not giving access to
branches in OFBiz project to people who need more than a patch to submit in a
Jira (clearly Tom and I would have loved
On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
I even wonder if Jacopo did not make a more recent (and flexible) proposition
with which I totaly agreed (during fall, it seems to me but, I can't find
it), Jacopo?
Do you mean the following?
BTW, some time ago I
Yes thanks!
Jacques
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
I even wonder if Jacopo did not make a more recent (and flexible)
proposition with which I totaly agreed (during fall, it seems to me but, I
can't find it),
From: Nicolas Malin malin.nico...@librenberry.net
Le 15/11/2012 08:49, Jacques Le Roux a écrit :
I don't see much activity recently
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
Should we not focus a bit more on it?
Jacques
Hi all,
To continue on slim-down effort,
From: Jacques Le Roux jacques.le.r...@les7arts.com
From: Nicolas Malin malin.nico...@librenberry.net
Le 15/11/2012 08:49, Jacques Le Roux a écrit :
I don't see much activity recently
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
Should we not focus a bit more on it?
Thanks jacques, create a wiki page sound good to me :)
Nicolas
Le 16/12/2012 14:28, Jacques Le Roux a écrit :
From: Jacques Le Roux jacques.le.r...@les7arts.com
From: Nicolas Malin malin.nico...@librenberry.net
Le 15/11/2012 08:49, Jacques Le Roux a écrit :
I don't see much activity
Le 15/11/2012 08:49, Jacques Le Roux a écrit :
I don't see much activity recently
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
Should we not focus a bit more on it?
Jacques
Hi all,
To continue on slim-down effort, I propose to work on a POC.
We define the expected to
On 11/20/2012 07:17 PM, Jacques Le Roux wrote:
No worries Adam,
Paul gave Yum just as a sort-of-like example. I don't know the addons
technology, but I'm sure it's not related at all with Yum or even apt-get
(more Ant and maybe Ivy)
And of course, we all prefer get-apt (at least I do,
Adam and I have been talking about a feature like this for a while. Its a good
question whether something like Maven would serve as a good basis for resolving
dependencies or maybe even a pluggable architecture. On Red Hat and Debian
systems you could even automatically bring in native
not mistaken, so propably not an option (but
somebody else should verify that again ;))
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637828.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
On 11/16/2012 05:40 AM, Jacques Le Roux wrote:
Very well summed up, Paul
Thanks
Jacques
From: madppiper p...@ilscipio.com
@jacopo: That sounds like a terrific idea of yours! I have to read up on
[Proposal], but from your outline here, i would say it is a more sincere
step.
No worries Adam,
Paul gave Yum just as a sort-of-like example. I don't know the addons
technology, but I'm sure it's not related at all with Yum or even apt-get (more
Ant and maybe Ivy)
And of course, we all prefer get-apt (at least I do, actually I don't even know
Yum :D)
Jacques
From:
Please see inline:
On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote:
Hi Jacopo,
So apart the next step is to move all specialpurpose components to Apache
Extras. Are we still all OK to do that?
I don't think we should move all specialpurpose components out of the project,
and for sure
Inline...
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
Please see inline:
On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote:
Hi Jacopo,
So apart the next step is to move all specialpurpose components to Apache
Extras. Are we still all OK to do that?
I don't think we
everyone will say that I ramble but
I don't understand how it's possible to find a consensus on slim-down
boundary or what should be in ofbiz kernel if there is no simple process
to have a OFbiz with the selected functionalities.
I clearly speak about addon manager.
Some example to be more clear
On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote:
I don't understand how it's possible to find a consensus on slim-down
boundary or what should be in ofbiz kernel if there is no simple process
to have a OFbiz with the selected functionalities.
I clearly speak about addon manager.
Even if
- install
manager) could be beneficial to whatever we come up with here. But the tool
for me is an addition to the proposal above, it is not a contradiction to
it.
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637667.html
Sent from
.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637667.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Le 16/11/2012 11:37, Jacopo Cappellato a écrit :
On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote:
I don't understand how it's possible to find a consensus on slim-down
boundary or what should be in ofbiz kernel if there is no simple process
to have a OFbiz with the selected
On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote:
It's to decrease the number of step to install, to help people (IT user,
not end user I know)
Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to
have tool but not mandatory to use external tools.
Regards,
Jacopo
On Nov 16, 2012, at 3:53 PM, Jacopo Cappellato wrote:
Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice
to have tool but not mandatory to use external tools.
oops... errata corrige:
... but not mandatory to use external tools --- ... but not mandatory to
use
Thank you Jacques.
I am going to work on the debian removal, that should be quick.
Another important milestone would be the creation of an extras.html page for
our website where we could list:
1) the components for OFBiz managed out of the OFBiz as Apache Extras
2) the components moved to Attic
Hi Jacopo,
So apart the next step is to move all specialpurpose components to Apache
Extras. Are we still all OK to do that?
I heard here and there that not all the community is expecting good from this
move.
Like less attention to moved components or new component going only to Apache
In general i agree with this action however,
1. components which need to be integrated with components like help and
reporting (birt) in order to be useful and which are essential for the
functionality of the system, i do not agree:
help
Birt
2. further the following components are standard
this, but why
not choose a better way that sets the incentives right?
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637653.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
I tend to agree with you Hans for those components, complements inline
From: Hans Bakker mailingl...@antwebsystems.com
In general i agree with this action however,
1. components which need to be integrated with components like help and
reporting (birt) in order to be useful and which are
I don't see much activity recently
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
Should we not focus a bit more on it?
Jacques
45 matches
Mail list logo
