[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Sorry, I'm currently swamped and won't find time to look into this for the 
coming days. @sesuncedu there is a discussion going on on the dev mailing list 
that you may want to join -> 
https://lists.apache.org/thread.html/4a205ffad0ae0886113e76f358a6fbe59dfdf113f194c5fa687cdd69@%3Cdev.commons.apache.org%3E


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
A key point is that these  files that are not modified for each release.
They are only changed when the package version changes, which only happens
when  the API changes (and was supposed to).
If the package API does  not change, then the package version should _not_
be modified.

Also, changing the package version number happens in the development phase
of the lifecycle rather than the release phase.

On Mon, Jun 5, 2017, 6:26 PM Jörg Schaible  
wrote:

> ... and again we have a bunch of files that we have to modify for every
> release.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[joehni]

Github user joehni commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
... and again we have a bunch of files that we have to modify for every 
release.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[joehni]

Github user joehni commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
This is a Maven project and we follow Maven conventions. Anything that is 
processed by a Java compiler belongs into src/main/java (true for 
package-info.java files, not true for packageinfo files or package.html files). 
Anything else that should be collected in a jar file is a resource and belongs 
therefore into src/main/resources. The fact that you have to reconfigure the 
resources clearly demonstrates this.

Nevertheless, these files will make our release process even more 
cumbersome if they are checked in as sources. The nature and content of the 
files identifies them clearly as something that can be generated. We might even 
be able to use the antrun plugin directly. If we put it into a profile and 
activate it based on file existence, we might even move it into commons-parent.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
The packageinfo files are in the source tree because they're source files,
and provide metadata for the package.
You can also use a package annotation on package-info.java, which puts a
Class Retention annotation on the packages package-info.class.

Examples:


https://github.com/apache/felix/blob/trunk/dependencymanager/org.apache.felix.dependencymanager.annotation/src/org/apache/felix/dm/annotation/api/packageinfo

https://github.com/apache/felix/blob/trunk/converter/
converter/src/main/java/org/apache/felix/converter/dto/package-info.java

(Requires provided / compileOnly dependency on the osgi annotation bundle).

On Fri, Jun 2, 2017 at 6:11 PM, Jörg Schaible 
wrote:

> Why are those packageinfo files in src/main/java instead of
> src/main/resources as it is common in Maven builds? Now you have to
> configure explicitly these files as resources. On top of it, I don't like
> the idea of modifying these files for each release manually. I'd look for 
a
> solution that generates these files automatically into
> target/generated-resources. Such a plugin should not be difficult.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[joehni]

Github user joehni commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Why are those packageinfo files in src/main/java instead of 
src/main/resources as it is common in Maven builds? Now you have to configure 
explicitly these files as resources. On top of it, I don't like the idea of 
modifying these files for each release manually. I'd look for a solution that 
generates these files automatically into target/generated-resources. Such a 
plugin should not be difficult.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
It's difficult to generalize, since the packageinfo files have to be put in
with the source code. Since a  export header parameter with an explicit
version overrides packageinfo and annotations, defaults can be problematic.

Adding the resource copy and rat excludes is good, as is keeping up with
the felix bundle versions.

Adding a bundle:baseline goal to the parent verify phase is a really,
really good idea if bundle headers are going to be generated. Package
versions MUST  follow semver (bundle versions also, but to a lesser
extent).


Maven versions theoretically ought to too, but dependencies are usually
point versions not ranges.

(Of course, there's always guava, where version is a major release, except
for bug fixes, which are minor.)

The real  work is getting the api and implementation(s) properly
modularized so that the api isn't always affected by implementation
changes.  At least jigsaw has gotten people to start thinking about
modules. Not always sensibly

On Jun 2, 2017 2:38 PM, "Gary Gregory"  wrote:

> Hi,
>
> Should any of this work also apply to commons-parent?
>
> Gary
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Hi,

Should any of this work also apply to commons-parent?

Gary


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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