Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ace-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ant.elder@gmail.com designates
 209.85.216.175 as permitted sender)
MIME-Version: 1.0
Reply-To: antelder@apache.org
Sender: ant.elder@gmail.com
In-Reply-To: 
 <CAJnwQNhAuCxETh+JuY1WcBs76Zuf2DpO-mOaxsGL-VAFDU455g@mail.gmail.com>
References: 
 <CAJO+UbsXq_+dHY=2kifpFmy_7qHVP33bk+7RuQc5uJ1-7upbHg@mail.gmail.com>
	<CAJnwQNhnqghusSojTVaTEHHDJaaYkXbB6xJEy=5fvgSXSkcyAg@mail.gmail.com>
	<9D2D7EFE-152D-43F4-A025-38435FAEEF25@luminis.nl>
	<CAJnwQNgrXxpF3PLaYbQYF-7M7X+1OdP+k+8=EN1m9hvyjA=B7A@mail.gmail.com>
	<CAJO+UbsRF5Kwhg9GFfH4WHdhPPTLQcCi9sRcbC9+59bwj_HmdA@mail.gmail.com>
	<CAKjo4PNpi6OCByV1Q4-Lf5+LG3BgmJ-J_+aOCYYM2DvVxcUKzA@mail.gmail.com>
	<CAJO+UbunXTp+_CMkB7Ge6AHPQOKyrb2Wj94-Vnb-SOJD1Jx1eA@mail.gmail.com>
	<CAKjo4POFXh8_nc4qGqp0=5SgiGttO1UJ+y0Ag-m5qTsTMcEnBg@mail.gmail.com>
	<CAJO+Ubu32KyKfNo52UPZUY=tZ9ejS8mSFFgNp0hXn+cqkjm2pw@mail.gmail.com>
	<CAJnwQNhAuCxETh+JuY1WcBs76Zuf2DpO-mOaxsGL-VAFDU455g@mail.gmail.com>
Date: Thu, 24 Nov 2011 15:34:16 +0000
Message-ID: 
 <CAJO+UbugKpqQOLtGK2zLXpePbnBAv_qQT3s2GiCZ5py5DdY9nA@mail.gmail.com>
Subject: Re: Next release
From: ant elder <antelder@apache.org>
To: ace-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 24, 2011 at 3:25 PM, Karl Pauls <karlpauls@gmail.com> wrote:
> On Thu, Nov 24, 2011 at 3:48 PM, ant elder <antelder@apache.org> wrote:
>> On Thu, Nov 24, 2011 at 1:51 PM, Bram de Kruijff <bdekruijff@gmail.com> =
wrote:
>>> On Thu, Nov 24, 2011 at 2:33 PM, ant elder <antelder@apache.org> wrote:
>>>> On Thu, Nov 24, 2011 at 1:14 PM, Bram de Kruijff <bdekruijff@gmail.com=
> wrote:
>>>>> On Thu, Nov 24, 2011 at 10:11 AM, ant elder <ant.elder@gmail.com> wro=
te:
>>>>>> On Wed, Nov 23, 2011 at 8:14 PM, Karl Pauls <karlpauls@gmail.com> wr=
ote:
>>>>>>> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
>>>>>>> <marcel.offermans@luminis.nl> wrote:
>>>>>>>> +1, I think providing such a script is a good way to do it, it mak=
es checking and building the individual components a lot easier whilst stil=
l maintaining the flexibility of being able to release any subset of artifa=
cts. 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 w=
ith
>>>>>>> ant and sebb on this one), it sucks rocks as you have to massage th=
e
>>>>>>> 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 - =A0but this way, we don't have to tag the trunk).
>>>>>>
>>>>>> If having the reactor pom would be even easier then why not do that?
>>>>>
>>>>> It's not that simple, cause the reactor does not know about versions.
>>>>> You could just zip the entire subversion, but this is not how these
>>>>> projects our structured as each module in principle has it's own
>>>>> life-cycle. For the same reason that tagging the entire trunk does no=
t
>>>>> make sense it would not make sense to release the infrastructural pom=
.
>>>>> True, ACE still uses a global version, but just look at Apache Felix
>>>>> and Sling and you'll know what I mean. IMHO, and I'm not an Apache
>>>>> person, the whole idea of having 1 release(version) is kind of
>>>>> artificial and antiquated. I can see why you need something like that
>>>>> as a promotion criteria for incubator, but at the same time you need
>>>>> to understand how these projects are structured and accept the fact
>>>>> that there is not one version to rule them all.
>>>>>
>>>>>> This isn't just about making it possible for reviewers to easily bui=
ld
>>>>>> the release when voting its about having a source release that you c=
an
>>>>>> 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 bui=
ld
>>>>>> was done and the projects refreshed, so really not a very practical
>>>>>> approach.
>>>>>
>>>>> I don't think this is a valid argument. This is how Maven releases
>>>>> work and it provides great support for developer that work against a
>>>>> released artifact. I declare a dependency to ace-something version
>>>>> x.y, my IDE dowloads the jar, the javadoc, the sources and I'm happy.
>>>>> There is no good support for setting up a full ace development
>>>>> environment from the Maven repository, because that's not how it
>>>>> intended to work. You use SCM to checkout project sources that you
>>>>> want to develop on, import them into your IDE and make all the magic
>>>>> work. You can't blame ACE for the fact that standard tools don't
>>>>> support a use-case that nobody actually needs... I think the principl=
e
>>>>> thing here is that, even if the subversion dies in a nuclear attack,
>>>>> you could do it from these release artifacts.
>>>>>
>>>>
>>>> So i think what you're saying is that a full source release isn't
>>>> needed because there is an SVN tag for the release which has
>>>> everything you need if you want to do ACE development. Is that what
>>>> you mean?
>>>
>>> Not exactly what I was trying to say :)
>>>
>>> There is (and should be) a full source release for all release
>>> artifacts (for that particular version) based on the standard Maven
>>> -sources and related artifacts in the release repository. Together
>>> these contain all information needed to be able to setup development
>>> in any IDE and yes it will require some manual labor or a shell script
>>> or whatever.
>>>
>>> But IMHO you cant attack that with a ease-of-use argument cause nobody
>>> (outside this particular audit case) will ever do it like that in real
>>> world development. If so there would be support for it already and if
>>> Apache still thinks it should be supported by all means let's start a
>>> mavenrepository2myIDE project. I personally think it's a bad idea
>>> though, because you still will end up with a filesystem layout mapping
>>> to different tags/version. Again, look at Apache Felix or Apache Sling
>>> and try to imagine how a full source release for these types of
>>> project would look like when mapped to SCM and then think of the
>>> usefulness...
>>>
>>
>> Apache Sling does do exactly whats been asked for - go to
>> http://sling.apache.org/site/downloads.cgi and see the "Sling Source
>> Package".
>
> Not really. As we mentioned several times, sling follows a mixed
> approach. Modules are released independently and sometimes a big bang
> release with all bundles is created. For example, the "Sling Source
> Package" in version 6 contains org.apache.sling.scripting.jsp in
> version 2.0.14 but the latest released version of that one is 2.0.18.
> Didn't see a combined source release for that one ...
>
> At sling, we follow what we do at felix with the exception that we
> sometimes do a big bang release which contains everything.
>

Right and that sounds totally fine. If theres a release of just sling
scripting 2.0.18 then just its source is released -
http://comments.gmane.org/gmane.comp.apache.sling.devel/22989 - and
when the big bang releases are done you get all the source. The ACE
0.8.0 release was a big bang type release and from previous comments
it sounds like those will happen for example 1.0.

  ...ant