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