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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
