Re: [jSPF] cost of supporting offline builds

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 7/29/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> As you know I'm working on a branch to make jSPF a multimodule product.
>>>> It took half an hour to prepare the modules and refactor the m2
>>>> descriptor
>>>> so to have 2 modules correctly managed by m2 but it already took a lot of
>>>> hours trying to make it build while offline.
>>>>
>>>> The "stage module" hack is too much against what m2 expects and it keep
>>>> giving me issues whenever I try to build the project using a different m2
>>>> sequence (package, install, site, site:stage, validate).
>>>>
>>>> Furthermore during the multimodule refactoring I had to remove the
>>>> build.xml
>>>> because it was no more working and no more mantained for the new
>>>> structure.
>>>>
>>>> Now I think in the last 2 years I lost full days of my work trying to
>>>> accomodate offline build capability using m2 hacks and this is now
>>>> starting
>>>> being frustrating.
>>>>
>>>> You can also add that this hack introduced new licensing issues because
>>>> NOT
>>>> A SINGLE pom published in maven repositories have a license header
>>>> telling
>>>> us what we can do with it.
>>>>
>>>> I'm happy with standard maven 2 and I don't care of offline builds so
>>>> much
>>>> to make this a blocking issue and I don't think that the build system
>>>> should
>>>> be given more importance than the produced artifacts.
>>>> Maven has a dependency:go-offline target specifically created for people
>>>> that want to go offline that take care of downloading and installing any
>>>> needed artifact in the local repository. This is what maven supports. I
>>>> would be happier if m2 bundled most standard plugins in its distribution
>>>> and
>>>> if m2 allowed packaging of a project including an offline repository, but
>>>> this is not the case.
>>>>
>>>> That said I'd like to remove build.xml from jSPF because no one is
>>>> mantaining it and I'd also like to remove offline build support from jSPF
>>>> so
>>>> I can start caring of code and output artifacts instead of this stuff.
>>>>
>>>> If people don't want to loose this then I'll close the branch
>>>> "multimodule-proposal" because the amount of work needed to mantain
>>>> ant+m2+m2-offline-support is too much in a multimodule product.
>>>>
>>>> Unless someone comes with good ideas about managing this stuff or take
>>>> the
>>>> responsibility to mantain that build system I'm going to start a VOTE to
>>>> remove ant support and m2 offline build support from jSPF.
>>> i'd probably approach this a little differently. i'm not sure a VOTE
>>> is really necessary or indeed a good idea.
>>>
>>> if anyone wants to volunteer to create and maintain an ant build
>>> including offline support for jSPF then that's cool by me and i'd have
>>> no problem keeping it in. if no one is willing to maintain an ant
>>> build including offline support (and i'm not for this product) then it
>>> should be removed. in either case, it's about individuals caring
>>> enough about a feature to step up and maintain it, not about some vote
>>> by the general community.
>>>
>>> so i'd just post a email such as this and then ask if anyone cares
>>> enough about this feature to volunteer to maintain it.
>>>
>>> but this is just my 2 cents...
>> I love this approach and I hope the rest of the PMC share your opinion!
>>
>> I also agree that similar stuff shouldn't need a VOTE, but I proposed a
>> VOTE because the last time build.xml has not been updated we had a
>> number of complaint for people that was against a release not including
>> a working build.xml. So a the VOTE was intended to not hide this change
>> in a simple message, but instead make the community aware of the issue
>> in the spirit of the least surprise.
> 
> A VOTE now will not stop objections when it comes to a release

No one else commented on this.

So, do you propose I simply go ahead and ignore m2 offline builds and 
ant builds?

My main concern is that I don't want to waste my time working on this. 
If people will have to complain later I prefer them to complain now. I'm 
used to people complaining for everything here, but if you think this 
kind of stuff should be managed as you proposed and a that I should not 
call a vote I'll trust your experience and proceed along that line (that 
would also be my preffered way to work).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [jSPF] cost of supporting offline builds

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 6:59 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> it's better to use a PROPOSAL or a POLL and then moved gradually
>> trying to carry the community with me (or at least as many who wanted
>> to come along), or just invoked Rules For Revolutionaries and forked
>
> Done. Just wrote a PROPOSAL. How much should I wait before proceeding in the
> case no one object? (this thread is 6 days old.. maybe another week for the
> PROPOSAL thread is enough?)

it's a judgement call. it's not a VOTE with a formal end set. there's
no need to total a result or anything. just a change to gauge and
build a consensus. if no one seems particularly bothered then just go
ahead.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [jSPF] cost of supporting offline builds

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> it's better to use a PROPOSAL or a POLL and then moved gradually
> trying to carry the community with me (or at least as many who wanted
> to come along), or just invoked Rules For Revolutionaries and forked

Done. Just wrote a PROPOSAL. How much should I wait before proceeding in 
the case no one object? (this thread is 6 days old.. maybe another week 
for the PROPOSAL thread is enough?)

>> so I will follow your suggestion and skip the vote now.
> 
> it's important to keep talking so that everyone has a chance to
> realise what's happening

No problem, I'm good at this. I'll reply to anyone asking questions. I 
still have to find the right balance to avoid both people complaining 
because I act without discussing and people comlaining because I act 
with too much discussions.

"Getting things done" is hard here, and I have no codebase issues.

I appreciate your help, indeed, even if I don't hide that I'm a lot 
skeptic about the whole thing.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [jSPF] cost of supporting offline builds

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 5:46 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Aug 4, 2008 at 3:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On 7/29/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>>>
>>>>> Robert Burrell Donkin ha scritto:
>>>>>>
>>>>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <ap...@bago.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> As you know I'm working on a branch to make jSPF a multimodule
>>>>>>> product.
>>>>>>> It took half an hour to prepare the modules and refactor the m2
>>>>>>> descriptor
>>>>>>> so to have 2 modules correctly managed by m2 but it already took a
>>>>>>> lot
>>>>>>> of
>>>>>>> hours trying to make it build while offline.
>>>>>>>
>>>>>>> The "stage module" hack is too much against what m2 expects and it
>>>>>>> keep
>>>>>>> giving me issues whenever I try to build the project using a
>>>>>>> different
>>>>>>> m2
>>>>>>> sequence (package, install, site, site:stage, validate).
>>>>>>>
>>>>>>> Furthermore during the multimodule refactoring I had to remove the
>>>>>>> build.xml
>>>>>>> because it was no more working and no more mantained for the new
>>>>>>> structure.
>>>>>>>
>>>>>>> Now I think in the last 2 years I lost full days of my work trying to
>>>>>>> accomodate offline build capability using m2 hacks and this is now
>>>>>>> starting
>>>>>>> being frustrating.
>>>>>>>
>>>>>>> You can also add that this hack introduced new licensing issues
>>>>>>> because
>>>>>>> NOT
>>>>>>> A SINGLE pom published in maven repositories have a license header
>>>>>>> telling
>>>>>>> us what we can do with it.
>>>>>>>
>>>>>>> I'm happy with standard maven 2 and I don't care of offline builds so
>>>>>>> much
>>>>>>> to make this a blocking issue and I don't think that the build system
>>>>>>> should
>>>>>>> be given more importance than the produced artifacts.
>>>>>>> Maven has a dependency:go-offline target specifically created for
>>>>>>> people
>>>>>>> that want to go offline that take care of downloading and installing
>>>>>>> any
>>>>>>> needed artifact in the local repository. This is what maven supports.
>>>>>>> I
>>>>>>> would be happier if m2 bundled most standard plugins in its
>>>>>>> distribution
>>>>>>> and
>>>>>>> if m2 allowed packaging of a project including an offline repository,
>>>>>>> but
>>>>>>> this is not the case.
>>>>>>>
>>>>>>> That said I'd like to remove build.xml from jSPF because no one is
>>>>>>> mantaining it and I'd also like to remove offline build support from
>>>>>>> jSPF
>>>>>>> so
>>>>>>> I can start caring of code and output artifacts instead of this
>>>>>>> stuff.
>>>>>>>
>>>>>>> If people don't want to loose this then I'll close the branch
>>>>>>> "multimodule-proposal" because the amount of work needed to mantain
>>>>>>> ant+m2+m2-offline-support is too much in a multimodule product.
>>>>>>>
>>>>>>> Unless someone comes with good ideas about managing this stuff or
>>>>>>> take
>>>>>>> the
>>>>>>> responsibility to mantain that build system I'm going to start a VOTE
>>>>>>> to
>>>>>>> remove ant support and m2 offline build support from jSPF.
>>>>>>
>>>>>> i'd probably approach this a little differently. i'm not sure a VOTE
>>>>>> is really necessary or indeed a good idea.
>>>>>>
>>>>>> if anyone wants to volunteer to create and maintain an ant build
>>>>>> including offline support for jSPF then that's cool by me and i'd have
>>>>>> no problem keeping it in. if no one is willing to maintain an ant
>>>>>> build including offline support (and i'm not for this product) then it
>>>>>> should be removed. in either case, it's about individuals caring
>>>>>> enough about a feature to step up and maintain it, not about some vote
>>>>>> by the general community.
>>>>>>
>>>>>> so i'd just post a email such as this and then ask if anyone cares
>>>>>> enough about this feature to volunteer to maintain it.
>>>>>>
>>>>>> but this is just my 2 cents...
>>>>>
>>>>> I love this approach and I hope the rest of the PMC share your opinion!
>>>>>
>>>>> I also agree that similar stuff shouldn't need a VOTE, but I proposed a
>>>>> VOTE because the last time build.xml has not been updated we had a
>>>>> number of complaint for people that was against a release not including
>>>>> a working build.xml. So a the VOTE was intended to not hide this change
>>>>> in a simple message, but instead make the community aware of the issue
>>>>> in the spirit of the least surprise.
>>>>
>>>> A VOTE now will not stop objections when it comes to a release
>>>
>>> No one else commented on this.
>>>
>>> So, do you propose I simply go ahead and ignore m2 offline builds and ant
>>> builds?
>>>
>>> My main concern is that I don't want to waste my time working on this. If
>>> people will have to complain later I prefer them to complain now. I'm
>>> used
>>> to people complaining for everything here, but if you think this kind of
>>> stuff should be managed as you proposed and a that I should not call a
>>> vote
>>> I'll trust your experience and proceed along that line (that would also
>>> be
>>> my preffered way to work).
>>
>> calling a VOTE now does not bind voters for the future: when it comes
>> to a release, people may decide that they really want an offline build
>> and that's what's required. if so then one can be added.
>
> I thought that a collaborative environment is made by people that know today
> if they will vote down a release tomorrow because of a specific issue.

no one knows what'll happen tomorrow :-)

just decide on today's issues

> But I already had bad experience even when I called the VOTE for a shared
> goal (the famous unanimous vote about next-major almost 2 years ago) and
> then people said I was pushing my own goals,

VOTEs like this are usually a mistake

it's better to use a PROPOSAL or a POLL and then moved gradually
trying to carry the community with me (or at least as many who wanted
to come along), or just invoked Rules For Revolutionaries and forked

> so I will follow your suggestion and skip the vote now.

it's important to keep talking so that everyone has a chance to
realise what's happening

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [jSPF] cost of supporting offline builds

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, Aug 4, 2008 at 3:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 7/29/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>> As you know I'm working on a branch to make jSPF a multimodule product.
>>>>>> It took half an hour to prepare the modules and refactor the m2
>>>>>> descriptor
>>>>>> so to have 2 modules correctly managed by m2 but it already took a lot
>>>>>> of
>>>>>> hours trying to make it build while offline.
>>>>>>
>>>>>> The "stage module" hack is too much against what m2 expects and it keep
>>>>>> giving me issues whenever I try to build the project using a different
>>>>>> m2
>>>>>> sequence (package, install, site, site:stage, validate).
>>>>>>
>>>>>> Furthermore during the multimodule refactoring I had to remove the
>>>>>> build.xml
>>>>>> because it was no more working and no more mantained for the new
>>>>>> structure.
>>>>>>
>>>>>> Now I think in the last 2 years I lost full days of my work trying to
>>>>>> accomodate offline build capability using m2 hacks and this is now
>>>>>> starting
>>>>>> being frustrating.
>>>>>>
>>>>>> You can also add that this hack introduced new licensing issues because
>>>>>> NOT
>>>>>> A SINGLE pom published in maven repositories have a license header
>>>>>> telling
>>>>>> us what we can do with it.
>>>>>>
>>>>>> I'm happy with standard maven 2 and I don't care of offline builds so
>>>>>> much
>>>>>> to make this a blocking issue and I don't think that the build system
>>>>>> should
>>>>>> be given more importance than the produced artifacts.
>>>>>> Maven has a dependency:go-offline target specifically created for
>>>>>> people
>>>>>> that want to go offline that take care of downloading and installing
>>>>>> any
>>>>>> needed artifact in the local repository. This is what maven supports. I
>>>>>> would be happier if m2 bundled most standard plugins in its
>>>>>> distribution
>>>>>> and
>>>>>> if m2 allowed packaging of a project including an offline repository,
>>>>>> but
>>>>>> this is not the case.
>>>>>>
>>>>>> That said I'd like to remove build.xml from jSPF because no one is
>>>>>> mantaining it and I'd also like to remove offline build support from
>>>>>> jSPF
>>>>>> so
>>>>>> I can start caring of code and output artifacts instead of this stuff.
>>>>>>
>>>>>> If people don't want to loose this then I'll close the branch
>>>>>> "multimodule-proposal" because the amount of work needed to mantain
>>>>>> ant+m2+m2-offline-support is too much in a multimodule product.
>>>>>>
>>>>>> Unless someone comes with good ideas about managing this stuff or take
>>>>>> the
>>>>>> responsibility to mantain that build system I'm going to start a VOTE
>>>>>> to
>>>>>> remove ant support and m2 offline build support from jSPF.
>>>>> i'd probably approach this a little differently. i'm not sure a VOTE
>>>>> is really necessary or indeed a good idea.
>>>>>
>>>>> if anyone wants to volunteer to create and maintain an ant build
>>>>> including offline support for jSPF then that's cool by me and i'd have
>>>>> no problem keeping it in. if no one is willing to maintain an ant
>>>>> build including offline support (and i'm not for this product) then it
>>>>> should be removed. in either case, it's about individuals caring
>>>>> enough about a feature to step up and maintain it, not about some vote
>>>>> by the general community.
>>>>>
>>>>> so i'd just post a email such as this and then ask if anyone cares
>>>>> enough about this feature to volunteer to maintain it.
>>>>>
>>>>> but this is just my 2 cents...
>>>> I love this approach and I hope the rest of the PMC share your opinion!
>>>>
>>>> I also agree that similar stuff shouldn't need a VOTE, but I proposed a
>>>> VOTE because the last time build.xml has not been updated we had a
>>>> number of complaint for people that was against a release not including
>>>> a working build.xml. So a the VOTE was intended to not hide this change
>>>> in a simple message, but instead make the community aware of the issue
>>>> in the spirit of the least surprise.
>>> A VOTE now will not stop objections when it comes to a release
>> No one else commented on this.
>>
>> So, do you propose I simply go ahead and ignore m2 offline builds and ant
>> builds?
>>
>> My main concern is that I don't want to waste my time working on this. If
>> people will have to complain later I prefer them to complain now. I'm used
>> to people complaining for everything here, but if you think this kind of
>> stuff should be managed as you proposed and a that I should not call a vote
>> I'll trust your experience and proceed along that line (that would also be
>> my preffered way to work).
> 
> calling a VOTE now does not bind voters for the future: when it comes
> to a release, people may decide that they really want an offline build
> and that's what's required. if so then one can be added.

I thought that a collaborative environment is made by people that know 
today if they will vote down a release tomorrow because of a specific issue.

But I already had bad experience even when I called the VOTE for a 
shared goal (the famous unanimous vote about next-major almost 2 years 
ago) and then people said I was pushing my own goals, so I will follow 
your suggestion and skip the vote now.

In the worst case we'll stop having new releases for jSPF, too. In the 
end is the only product having a release in the last year, so this seems 
a natural future ;-)

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [jSPF] cost of supporting offline builds

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Aug 4, 2008 at 3:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 7/29/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>>
>>>>> As you know I'm working on a branch to make jSPF a multimodule product.
>>>>> It took half an hour to prepare the modules and refactor the m2
>>>>> descriptor
>>>>> so to have 2 modules correctly managed by m2 but it already took a lot
>>>>> of
>>>>> hours trying to make it build while offline.
>>>>>
>>>>> The "stage module" hack is too much against what m2 expects and it keep
>>>>> giving me issues whenever I try to build the project using a different
>>>>> m2
>>>>> sequence (package, install, site, site:stage, validate).
>>>>>
>>>>> Furthermore during the multimodule refactoring I had to remove the
>>>>> build.xml
>>>>> because it was no more working and no more mantained for the new
>>>>> structure.
>>>>>
>>>>> Now I think in the last 2 years I lost full days of my work trying to
>>>>> accomodate offline build capability using m2 hacks and this is now
>>>>> starting
>>>>> being frustrating.
>>>>>
>>>>> You can also add that this hack introduced new licensing issues because
>>>>> NOT
>>>>> A SINGLE pom published in maven repositories have a license header
>>>>> telling
>>>>> us what we can do with it.
>>>>>
>>>>> I'm happy with standard maven 2 and I don't care of offline builds so
>>>>> much
>>>>> to make this a blocking issue and I don't think that the build system
>>>>> should
>>>>> be given more importance than the produced artifacts.
>>>>> Maven has a dependency:go-offline target specifically created for
>>>>> people
>>>>> that want to go offline that take care of downloading and installing
>>>>> any
>>>>> needed artifact in the local repository. This is what maven supports. I
>>>>> would be happier if m2 bundled most standard plugins in its
>>>>> distribution
>>>>> and
>>>>> if m2 allowed packaging of a project including an offline repository,
>>>>> but
>>>>> this is not the case.
>>>>>
>>>>> That said I'd like to remove build.xml from jSPF because no one is
>>>>> mantaining it and I'd also like to remove offline build support from
>>>>> jSPF
>>>>> so
>>>>> I can start caring of code and output artifacts instead of this stuff.
>>>>>
>>>>> If people don't want to loose this then I'll close the branch
>>>>> "multimodule-proposal" because the amount of work needed to mantain
>>>>> ant+m2+m2-offline-support is too much in a multimodule product.
>>>>>
>>>>> Unless someone comes with good ideas about managing this stuff or take
>>>>> the
>>>>> responsibility to mantain that build system I'm going to start a VOTE
>>>>> to
>>>>> remove ant support and m2 offline build support from jSPF.
>>>>
>>>> i'd probably approach this a little differently. i'm not sure a VOTE
>>>> is really necessary or indeed a good idea.
>>>>
>>>> if anyone wants to volunteer to create and maintain an ant build
>>>> including offline support for jSPF then that's cool by me and i'd have
>>>> no problem keeping it in. if no one is willing to maintain an ant
>>>> build including offline support (and i'm not for this product) then it
>>>> should be removed. in either case, it's about individuals caring
>>>> enough about a feature to step up and maintain it, not about some vote
>>>> by the general community.
>>>>
>>>> so i'd just post a email such as this and then ask if anyone cares
>>>> enough about this feature to volunteer to maintain it.
>>>>
>>>> but this is just my 2 cents...
>>>
>>> I love this approach and I hope the rest of the PMC share your opinion!
>>>
>>> I also agree that similar stuff shouldn't need a VOTE, but I proposed a
>>> VOTE because the last time build.xml has not been updated we had a
>>> number of complaint for people that was against a release not including
>>> a working build.xml. So a the VOTE was intended to not hide this change
>>> in a simple message, but instead make the community aware of the issue
>>> in the spirit of the least surprise.
>>
>> A VOTE now will not stop objections when it comes to a release
>
> No one else commented on this.
>
> So, do you propose I simply go ahead and ignore m2 offline builds and ant
> builds?
>
> My main concern is that I don't want to waste my time working on this. If
> people will have to complain later I prefer them to complain now. I'm used
> to people complaining for everything here, but if you think this kind of
> stuff should be managed as you proposed and a that I should not call a vote
> I'll trust your experience and proceed along that line (that would also be
> my preffered way to work).

calling a VOTE now does not bind voters for the future: when it comes
to a release, people may decide that they really want an offline build
and that's what's required. if so then one can be added.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org