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 Robert > > Let's see other's opinions! > > Thank you, > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
