ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <>
Subject Re: Next release
Date Thu, 24 Nov 2011 15:16:42 GMT
On Thu, Nov 24, 2011 at 3:48 PM, ant elder <> wrote:
> On Thu, Nov 24, 2011 at 1:51 PM, Bram de Kruijff <> wrote:
>> On Thu, Nov 24, 2011 at 2:33 PM, ant elder <> wrote:
>>> On Thu, Nov 24, 2011 at 1:14 PM, Bram de Kruijff <>
>>>> On Thu, Nov 24, 2011 at 10:11 AM, ant elder <> wrote:
>>>>> On Wed, Nov 23, 2011 at 8:14 PM, Karl Pauls <>
>>>>>> 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
>>>>>> 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
>>>>>> ant and sebb on this one), it sucks rocks as you have to massage
>>>>>> 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
>>>>>> 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
> and see the "Sling Source
> Package".

Yes, and to me (as a non apache non sling member who does not whishes
to offend anyway) it illustrates a couple of things....

1) They took a creative approach to the problem I illustrated by using
svn:externals to link it all together. See [0].
2) They do not in anyway advocate the use of this package to
developers (because it make no sense), but refer to svn for a proper
co. See [1].
3) They have abandoned the practice since (ecause it make no sense)
abd have not updated that initial package. See [2]

Actually, just guessing here, but from the the looks of it I think
someone was arguing they had to do it for graduation and thus did it
to end the debate ;) Notice how that tag was made more then a year
after the initial 6 tag.



>   ...ant

View raw message