james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jSPF] cost of supporting offline builds
Date Mon, 04 Aug 2008 14:42:59 GMT
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. 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


Mime
View raw message