On Mon, Aug 4, 2008 at 5:46 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On Mon, Aug 4, 2008 at 3:42 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> Robert Burrell Donkin ha scritto: >>>> >>>> On 7/29/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Robert Burrell Donkin ha scritto: >>>>>> >>>>>> On Tue, Jul 29, 2008 at 9:41 AM, Stefano Bagnara <[EMAIL PROTECTED]> >>>>>> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
