Re: Parent POM and automatic module name

[sebb]

On 9 January 2018 at 12:30, Stephen Colebourne  wrote:
> This seems a lot more effort than just adding something to the pom.xml
> in the child project.
> Stephen

Agreed; it could be something as simple as a property define.

Note that if it is a file, then it needs to be added to the source
archive but ideally not the binary archive.

This is already true of pom.xml

> On 9 January 2018 at 12:11, Gilles  wrote:
>> Hi.
>>
>> My suggestion would be
>>   "profile.java_automatic_module_name"
>> in the top directory.
>>
>> Gilles
>>
>>
>> On Mon, 8 Jan 2018 22:23:08 -0800, Chas Honton wrote:
>>>
>>> Profile triggers in src/profiles?
>>>
>>> Chas
>>>
 On Jan 8, 2018, at 4:27 PM, sebb  wrote:

> On 8 January 2018 at 23:14, Jörg Schaible  wrote:
> Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:
>
>> On 8 January 2018 at 00:25, Jörg Schaible 
>> wrote:
>
>
> [snip]
>
 The component poms I checked all include a comment like "Temporary
 fix, remove this after this has implemented in parent pom". As these
 comments are not true anymore I will remove those I find.
>>>
>>>
>>> It is possible to define a profile in parent and trigger it as opt-in
>>> based on the existence of a file.
>>>
>>> Do we have any precedence for triggering profiles based on file
>>> existence in commons? Typical name patterns used are:
>>> - profile/ - profiles/
>>> - .profile
>>
>>
>> Yes, e.g. jacoco
>
>
> Found it:
>
> - src/site/resources/profile.
>
> However the location for these profile files does not make sense in
> general. And definitely not for a profile
> adding the module name :-/
>
> Alternatives? Common location for such a profile activation?


 src/site/resources was chosen because Jacoco is used for the site build.
 I don't think such files should should be moved.

 But by all means find somewhere else for new profile triggers.

> Cheers,
> Jörg
>
>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Parent POM and automatic module name

[Gilles]

On Tue, 9 Jan 2018 12:30:19 +, Stephen Colebourne wrote:
This seems a lot more effort than just adding something to the 
pom.xml

in the child project.


Yes, but is there a possibility that this "automatic name"
addition should be be removed in the future (and replaced
by ...)?
If so, having a file in the top directory is a "TODO" reminder.

[Sorry I do not know the detail of the requirement(s).]

Regards,
Gilles


Stephen

On 9 January 2018 at 12:11, Gilles  
wrote:

Hi.

My suggestion would be
  "profile.java_automatic_module_name"
in the top directory.

Gilles


On Mon, 8 Jan 2018 22:23:08 -0800, Chas Honton wrote:


Profile triggers in src/profiles?

Chas


On Jan 8, 2018, at 4:27 PM, sebb  wrote:

On 8 January 2018 at 23:14, Jörg Schaible  
wrote:

Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:

On 8 January 2018 at 00:25, Jörg Schaible 


wrote:



[snip]

The component poms I checked all include a comment like 
"Temporary
fix, remove this after this has implemented in parent pom". As 
these

comments are not true anymore I will remove those I find.



It is possible to define a profile in parent and trigger it as 
opt-in

based on the existence of a file.

Do we have any precedence for triggering profiles based on file
existence in commons? Typical name patterns used are:
- profile/ - profiles/
- .profile



Yes, e.g. jacoco



Found it:

- src/site/resources/profile.

However the location for these profile files does not make sense 
in

general. And definitely not for a profile
adding the module name :-/

Alternatives? Common location for such a profile activation?



src/site/resources was chosen because Jacoco is used for the site 
build.

I don't think such files should should be moved.

But by all means find somewhere else for new profile triggers.


Cheers,
Jörg





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

Re: Parent POM and automatic module name

[Stephen Colebourne]

This seems a lot more effort than just adding something to the pom.xml
in the child project.
Stephen

On 9 January 2018 at 12:11, Gilles  wrote:
> Hi.
>
> My suggestion would be
>   "profile.java_automatic_module_name"
> in the top directory.
>
> Gilles
>
>
> On Mon, 8 Jan 2018 22:23:08 -0800, Chas Honton wrote:
>>
>> Profile triggers in src/profiles?
>>
>> Chas
>>
>>> On Jan 8, 2018, at 4:27 PM, sebb  wrote:
>>>
 On 8 January 2018 at 23:14, Jörg Schaible  wrote:
 Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:

> On 8 January 2018 at 00:25, Jörg Schaible 
> wrote:


 [snip]

>>> The component poms I checked all include a comment like "Temporary
>>> fix, remove this after this has implemented in parent pom". As these
>>> comments are not true anymore I will remove those I find.
>>
>>
>> It is possible to define a profile in parent and trigger it as opt-in
>> based on the existence of a file.
>>
>> Do we have any precedence for triggering profiles based on file
>> existence in commons? Typical name patterns used are:
>> - profile/ - profiles/
>> - .profile
>
>
> Yes, e.g. jacoco


 Found it:

 - src/site/resources/profile.

 However the location for these profile files does not make sense in
 general. And definitely not for a profile
 adding the module name :-/

 Alternatives? Common location for such a profile activation?
>>>
>>>
>>> src/site/resources was chosen because Jacoco is used for the site build.
>>> I don't think such files should should be moved.
>>>
>>> But by all means find somewhere else for new profile triggers.
>>>
 Cheers,
 Jörg


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

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

Re: Parent POM and automatic module name

[Gilles]

Hi.

My suggestion would be
  "profile.java_automatic_module_name"
in the top directory.

Gilles

On Mon, 8 Jan 2018 22:23:08 -0800, Chas Honton wrote:

Profile triggers in src/profiles?

Chas


On Jan 8, 2018, at 4:27 PM, sebb  wrote:

On 8 January 2018 at 23:14, Jörg Schaible  
wrote:

Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:

On 8 January 2018 at 00:25, Jörg Schaible  
wrote:


[snip]

The component poms I checked all include a comment like 
"Temporary
fix, remove this after this has implemented in parent pom". As 
these

comments are not true anymore I will remove those I find.


It is possible to define a profile in parent and trigger it as 
opt-in

based on the existence of a file.

Do we have any precedence for triggering profiles based on file
existence in commons? Typical name patterns used are:
- profile/ - profiles/
- .profile


Yes, e.g. jacoco


Found it:

- src/site/resources/profile.

However the location for these profile files does not make sense in 
general. And definitely not for a profile

adding the module name :-/

Alternatives? Common location for such a profile activation?


src/site/resources was chosen because Jacoco is used for the site 
build.

I don't think such files should should be moved.

But by all means find somewhere else for new profile triggers.


Cheers,
Jörg





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

Re: Parent POM and automatic module name

[Chas Honton]

Profile triggers in src/profiles?

Chas

> On Jan 8, 2018, at 4:27 PM, sebb  wrote:
> 
>> On 8 January 2018 at 23:14, Jörg Schaible  wrote:
>> Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:
>> 
>>> On 8 January 2018 at 00:25, Jörg Schaible  wrote:
>> 
>> [snip]
>> 
> The component poms I checked all include a comment like "Temporary
> fix, remove this after this has implemented in parent pom". As these
> comments are not true anymore I will remove those I find.
 
 It is possible to define a profile in parent and trigger it as opt-in
 based on the existence of a file.
 
 Do we have any precedence for triggering profiles based on file
 existence in commons? Typical name patterns used are:
 - profile/ - profiles/
 - .profile
>>> 
>>> Yes, e.g. jacoco
>> 
>> Found it:
>> 
>> - src/site/resources/profile.
>> 
>> However the location for these profile files does not make sense in general. 
>> And definitely not for a profile
>> adding the module name :-/
>> 
>> Alternatives? Common location for such a profile activation?
> 
> src/site/resources was chosen because Jacoco is used for the site build.
> I don't think such files should should be moved.
> 
> But by all means find somewhere else for new profile triggers.
> 
>> Cheers,
>> Jörg
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

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

Re: Parent POM and automatic module name

[sebb]

On 8 January 2018 at 23:14, Jörg Schaible  wrote:
> Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:
>
>> On 8 January 2018 at 00:25, Jörg Schaible  wrote:
>
> [snip]
>
 The component poms I checked all include a comment like "Temporary
 fix, remove this after this has implemented in parent pom". As these
 comments are not true anymore I will remove those I find.
>>>
>>> It is possible to define a profile in parent and trigger it as opt-in
>>> based on the existence of a file.
>>>
>>> Do we have any precedence for triggering profiles based on file
>>> existence in commons? Typical name patterns used are:
>>>  - profile/ - profiles/
>>>  - .profile
>>
>> Yes, e.g. jacoco
>
> Found it:
>
>  - src/site/resources/profile.
>
> However the location for these profile files does not make sense in general. 
> And definitely not for a profile
> adding the module name :-/
>
> Alternatives? Common location for such a profile activation?

src/site/resources was chosen because Jacoco is used for the site build.
I don't think such files should should be moved.

But by all means find somewhere else for new profile triggers.

> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Parent POM and automatic module name

[Jörg Schaible]

Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:

> On 8 January 2018 at 00:25, Jörg Schaible  wrote:

[snip]

>>> The component poms I checked all include a comment like "Temporary
>>> fix, remove this after this has implemented in parent pom". As these
>>> comments are not true anymore I will remove those I find.
>>
>> It is possible to define a profile in parent and trigger it as opt-in
>> based on the existence of a file.
>>
>> Do we have any precedence for triggering profiles based on file
>> existence in commons? Typical name patterns used are:
>>  - profile/ - profiles/
>>  - .profile
> 
> Yes, e.g. jacoco

Found it:

 - src/site/resources/profile.

However the location for these profile files does not make sense in general. 
And definitely not for a profile 
adding the module name :-/

Alternatives? Common location for such a profile activation?

Cheers,
Jörg


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

Re: Parent POM and automatic module name

[sebb]

On 8 January 2018 at 00:25, Jörg Schaible  wrote:
> Am Sun, 07 Jan 2018 12:04:16 +0100 schrieb Pascal Schumacher:
>
>> Am 07.01.2018 um 11:10 schrieb Stefan Bodewig:
>>> My memory (which is old and failing frequently) claims we didn't want
>>> to put it into the parent as not all components can use automatic
>>> module names (net hasn't got a single package root IIRC) and so
>>> wewanted to leave it to the individual components.
>>
>> Thanks! Your memory is correct. As I understand it the feature was not
>> added because no way was found to make it opt-in for the modules. see:
>>
>> https://mail-archives.apache.org/mod_mbox/commons-dev/201706.mbox/%3C7A329A04-
> ABE8-47B8-9981-161229CE6BCB%40apache.org%3E
>>
>> The component poms I checked all include a comment like "Temporary fix,
>> remove this after this has implemented in parent pom". As these comments
>> are not true anymore I will remove those I find.
>
> It is possible to define a profile in parent and trigger it as opt-in based 
> on the existence of a file.
>
> Do we have any precedence for triggering profiles based on file existence in 
> commons? Typical name
> patterns used are:
>  - profile/
>  - profiles/
>  - .profile

Yes, e.g. jacoco

> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Parent POM and automatic module name

[Jörg Schaible]

Am Sun, 07 Jan 2018 12:04:16 +0100 schrieb Pascal Schumacher:

> Am 07.01.2018 um 11:10 schrieb Stefan Bodewig:
>> My memory (which is old and failing frequently) claims we didn't want
>> to put it into the parent as not all components can use automatic
>> module names (net hasn't got a single package root IIRC) and so
>> wewanted to leave it to the individual components.
> 
> Thanks! Your memory is correct. As I understand it the feature was not
> added because no way was found to make it opt-in for the modules. see:
> 
> https://mail-archives.apache.org/mod_mbox/commons-dev/201706.mbox/%3C7A329A04-
ABE8-47B8-9981-161229CE6BCB%40apache.org%3E
> 
> The component poms I checked all include a comment like "Temporary fix,
> remove this after this has implemented in parent pom". As these comments
> are not true anymore I will remove those I find.

It is possible to define a profile in parent and trigger it as opt-in based on 
the existence of a file.

Do we have any precedence for triggering profiles based on file existence in 
commons? Typical name 
patterns used are:
 - profile/
 - profiles/
 - .profile

Cheers,
Jörg


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

Re: Parent POM and automatic module name

[sebb]

Might be sensible to add a note to the parent pom to say why it does
not have the feature.

On 7 January 2018 at 11:04, Pascal Schumacher  wrote:
> Am 07.01.2018 um 11:10 schrieb Stefan Bodewig:
>>
>> My memory (which is old and failing frequently) claims we didn't want to
>> put it into the parent as not all components can use automatic module
>> names (net hasn't got a single package root IIRC) and so wewanted to
>> leave it to the individual components.
>
>
> Thanks! Your memory is correct. As I understand it the feature was not added
> because no way was found to make it opt-in for the modules. see:
>
> https://mail-archives.apache.org/mod_mbox/commons-dev/201706.mbox/%3C7A329A04-ABE8-47B8-9981-161229CE6BCB%40apache.org%3E
>
> The component poms I checked all include a comment like "Temporary fix,
> remove this after this has implemented in parent pom". As these comments are
> not true anymore I will remove those I find.
>
> Cheers,
> Pascal
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Parent POM and automatic module name

[Pascal Schumacher]

Am 07.01.2018 um 11:10 schrieb Stefan Bodewig:

My memory (which is old and failing frequently) claims we didn't want to
put it into the parent as not all components can use automatic module
names (net hasn't got a single package root IIRC) and so wewanted to
leave it to the individual components.


Thanks! Your memory is correct. As I understand it the feature was not 
added because no way was found to make it opt-in for the modules. see:


https://mail-archives.apache.org/mod_mbox/commons-dev/201706.mbox/%3C7A329A04-ABE8-47B8-9981-161229CE6BCB%40apache.org%3E

The component poms I checked all include a comment like "Temporary fix, 
remove this after this has implemented in parent pom". As these comments 
are not true anymore I will remove those I find.


Cheers,
Pascal

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

Re: Parent POM and automatic module name

[Stefan Bodewig]

On 2018-01-07, Pascal Schumacher wrote:

> Hello everybody,

> just noticed that Parent POM 43 does not seem to set the automatic
> module name in the jar manifest.

> Did I miss something you did we just forget to add the required
> maven-jar-plugin configuration?

My memory (which is old and failing frequently) claims we didn't want to
put it into the parent as not all components can use automatic module
names (net hasn't got a single package root IIRC) and so wewanted to
leave it to the individual components.

Stefan

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

Parent POM and automatic module name

[Pascal Schumacher]

Hello everybody,

just noticed that Parent POM 43 does not seem to set the automatic 
module name in the jar manifest.


Did I miss something you did we just forget to add the required 
maven-jar-plugin configuration?


-Pascal




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