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...
Anyway, while I was typing Karl more or less made the same argument
already... let's merge back to one thread :)
grz
Bram
