ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: Next release
Date Thu, 24 Nov 2011 13:27:34 GMT
On Thu, Nov 24, 2011 at 10:11 AM, ant elder <> wrote:
> On Wed, Nov 23, 2011 at 8:14 PM, Karl Pauls <> wrote:
>> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
>> <> wrote:
>>> +1, I think providing such a script is a good way to do it, it makes checking
and building the individual components a lot easier whilst still maintaining the flexibility
of being able to release any subset of artifacts. I also agree that we should correct the
oversight of not shipping the pom.xml file as part of the source distribution for future releases.
>> Yeah, again, that is just a configuration we have to set so that it
>> not only generates the -sources.jar but also the -project.{zip,tar.gz}
>> just like we do at felix. Without that (and there I totally agree with
>> ant and sebb on this one), it sucks rocks as you have to massage the
>> stuff quite a bit to get it to work and don't even have the tests,
>> etc. :-(.
>> I think having the -projects plus the two scripts are a good way to go
>> (technically, its close to releasing the reactor pom - which would be
>> even easier -  but this way, we don't have to tag the trunk).
> If having the reactor pom would be even easier then why not do that?

That is the problem. It would make it much easier to just release the
reactor because it ties everything together. However, at the same
time, it ties everything together which is what we are trying to

Our modules are individual projects and we don't want something that
ties them together. Look at it this way, we don't have a reactor pom
in the top of the apache svn root that builds all apache projects
trunks. Nor do we release it (and tag the complete apache svn this
way) whenever any projects wants to do a release. I know, its a
question of granularity but for us, we see our subprojects as
independent modules and like to handle them that way.

> This isn't just about making it possible for reviewers to easily build
> the release when voting its about having a source release that you can
> actually use to do development on the code. If you don't release the
> recator pom then for example how do you set up the source in a IDE -
> you'd have to manually go into each artifact any type something like
> mvn eclipse:eclipse, and even then that would give isolated eclipse
> projects so IDE refactoring wouldn't go across the projects and IDE
> changes in one project wouldn't be picked up until after a maven build
> was done and the projects refreshed, so really not a very practical
> approach.

Well, it is the approach I and others have been using for years.

Anyways, Yes, there are things I don't like about maven. Yes, there
are things I don't like about eclipse. Yes, there are things I don't
like about the combination of the two. Maybe the way to get out of
this is to revert to autotools and makefiles or start developing our
own build system/IDE that doesn't suffer from these kind of issues.
Regardless, for me, just because some toolchains don't support certain
things, is not enough reason to stop doing it the way we think it is
right as long as the people involved with the project have ways to
work with it that make sense to them.



>   ...ant

Karl Pauls

View raw message