commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: commons-parent maven pom highly broken?
Date Mon, 15 Dec 2014 10:21:21 GMT
On 13 December 2014 at 18:22, Mark Struberg <struberg@yahoo.de> wrote:
> Just file an JIRA if something doesn't work and you are done.

Not sure what you are referring to there, but if it was my comments
about ASF pom bugs, I did file bugs, but as I recall, nothing happened
for over a year.

>
>> Releasing is tedious because Maven does not really support non-Maven
>> release directories (i.e. www.apache.org/dist/commons)
> This is totally non-ASF style. Just use the standard stuff like every other ASF project
and you are again done.

That's all well and good, but if the output is not correct (as it was
not) then that is not helpful.

>
>> Until very recently the ASF parent pom was broken, and with no sign of
>> any fixes.To me'not fixing anything' would mean that all the apache-parent releases
would be useless?
>
> Or you just did not check it?

Again, not sure what this is responding to.

>
>> There are stil issues with LICENSE and NOTICE, because the
>> automatically created ones are not always correct.
> The rule is straight forward. If you provide your own one then it will be used. If not,
then a standard one will be packaged.

>
>> The Commons Pom includes a lot of common setup that would otherwise
>> have to be added to each component's parent pom.
> And that would be? Most of the stuff is taken over from the old ant builds and nowadays
do not reflect reality anymore.
>

Standard reports
Standard Manifest settings
Mailing list names
N&L files in test & javadoc jars
Enforcer
Fixing bug in Felix
Standardise JIRA and changes report
etc.

As I already wrote, there is a lot of common Commons stuff that needs
to go somewhere.
It cannot go in the ASF pom.

Then there are utility optional profiles:
- jacoco
- cobertura
- java-1.x - allows build/test with different Java from default used
to run Maven
- test-deploy
- release-notes

Of course all of these could be deployed in component poms on an
as-needed basis.
But that rather goes against the spirit of re-usable code.


>> There are various other additional optional features in the Commons
>> pom which are useful for testing.
> what more than testng OR junit (depending on the project) + maybe mock tools do you need?
>

Not Unit testing - see above.

>
>> I think the CP pom works fine for single module projects.
>> I'm not sure about multimodule projects, but is the ASF pom any better?
> Well, most of todays projects are multi-module ones.

That is not true of Commons.
Which is probably why there are some issues with such components.

> And this works perfectly fine with the ASF parent pom.
>

Are you sure?
Have you checked that all the generated artifacts are complete?

The Commons Parent pom is intended to abstract common functions which
would otherwise be needed in all Commons components.
If there are aspects of it that are not working, file JIRAs that
clearly state what the problem is:
- what you tried
- what happened
- what you expected to happen

>
>
> LieGrue,
> strub
>
>
>
>
>> On Saturday, 13 December 2014, 18:41, sebb <sebbaz@gmail.com> wrote:
>> > On 13 December 2014 at 12:26, Mark Struberg <struberg@yahoo.de> wrote:
>>>  Hi!
>>>
>>>  I've never seen any other ASF project where it is such a torture to
>> release.
>>>  This is partly because the quality level is really high, but a big part of
>> it is that we don't have a mature parent pom.
>>
>> Sorry, but I don't think that is at all relevant.
>> Releasing is tedious because Maven does not really support non-Maven
>> release directories (i.e. www.apache.org/dist/commons) so work-rounds
>> are needed.
>> This is true whatever the parent pom is used.
>>
>> It's partly also that Maven does some things well, but when
>> adjustments are needed, it can be all but impossible to work out how
>> to coax it to do what's needed.
>>
>>>
>>>  I have no clue why we don't just use the common apache parent pom.
>> I've NEVER experienced such issues like missing NOTICE and LICENSE with it.
>> It's really much more solid than our own one.
>>
>> Until very recently the ASF parent pom was broken, and with no sign of
>> any fixes.
>> For example, it did not allow override of the compiler plugin version,
>> and there were a few other issues with it.
>>
>> There are stil issues with LICENSE and NOTICE, because the
>> automatically created ones are not always correct.
>> I'm not sure it creates the appropriate source and javadoc jars either.
>>
>> And it does not create decent manifests.
>>
>> The Commons Pom includes a lot of common setup that would otherwise
>> have to be added to each component's parent pom.
>> That is not an efficient way of proceeding.
>>
>> There are various other additional optional features in the Commons
>> pom which are useful for testing.
>>
>> I think the CP pom works fine for single module projects.
>> I'm not sure about multimodule projects, but is the ASF pom any better?
>>
>> Rather than raise unsubstantiated criticisms of the CP pom, file bugs
>> for any problems and/or try fixing them.
>>
>>
>>>  LieGrue,
>>>  strub
>>>
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>  For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message