james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [jSPF] cost of supporting offline builds
Date Mon, 04 Aug 2008 17:32:25 GMT
On Mon, Aug 4, 2008 at 5:46 PM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Mon, Aug 4, 2008 at 3:42 PM, Stefano Bagnara <apache@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On 7/29/08, Stefano Bagnara <apache@bago.org> wrote:
>>>>> Robert Burrell Donkin ha scritto:
>>>>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <apache@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
>>>>>>> descriptor
>>>>>>> so to have 2 modules correctly managed by m2 but it already took
>>>>>>> lot
>>>>>>> of
>>>>>>> hours trying to make it build while offline.
>>>>>>> The "stage module" hack is too much against what m2 expects and
>>>>>>> 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
>>>>>>> build.xml
>>>>>>> because it was no more working and no more mantained for the
>>>>>>> structure.
>>>>>>> Now I think in the last 2 years I lost full days of my work trying
>>>>>>> accomodate offline build capability using m2 hacks and this is
>>>>>>> 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
>>>>>>> much
>>>>>>> to make this a blocking issue and I don't think that the build
>>>>>>> should
>>>>>>> be given more importance than the produced artifacts.
>>>>>>> Maven has a dependency:go-offline target specifically created
>>>>>>> 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
>>>>>>> mantaining it and I'd also like to remove offline build support
>>>>>>> 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
>>>>>>> take
>>>>>>> the
>>>>>>> responsibility to mantain that build system I'm going to start
>>>>>>> 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
>>>>>> 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
>>>>>> should be removed. in either case, it's about individuals caring
>>>>>> enough about a feature to step up and maintain it, not about some
>>>>>> 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
>>>>> 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

View raw message