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?
We will provide all source, just not the reactor pom and just not as
one artifact but several -project.zips. If your IDE can't handle that
in they way you like it - how is that our fault? I would assume that
is something to fix in the IDE or its maven support. Anyhow, are you
arguing that it should be a requirement for incubator releases that
they are easily importable into eclipse?
regards,
Karl
> ...ant
>
--
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
