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


Mime
View raw message