On Thu, Nov 24, 2011 at 1:51 PM, Bram de Kruijff <bdekrui...@gmail.com> wrote:
> On Thu, Nov 24, 2011 at 2:33 PM, ant elder <antel...@apache.org> wrote:
>> On Thu, Nov 24, 2011 at 1:14 PM, Bram de Kruijff <bdekrui...@gmail.com>
>> wrote:
>>> On Thu, Nov 24, 2011 at 10:11 AM, ant elder <ant.el...@gmail.com> wrote:
>>>> On Wed, Nov 23, 2011 at 8:14 PM, Karl Pauls <karlpa...@gmail.com> wrote:
>>>>> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
>>>>> <marcel.offerm...@luminis.nl> 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?
>>>
>>> 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 not
>>> 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 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.
>>>
>>> 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 principle
>>> 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".
...ant
