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 16:33:00 GMT
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 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.
>>>>> 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

View raw message