Re: Building org.apache.felix.jaas fails

[Chetan Mehrotra]

Hi Robert,

Whats the mvn+java version you are using. I tried with latest trunk
and it build fine

mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T22:59:23+05:30)
Maven home: xxx/apache-maven-3.2.5
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: xxx/jdk/jdk1.7.0_55/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-37-generic", arch: "amd64", family: "unix"
Chetan Mehrotra


On Thu, Oct 22, 2015 at 2:58 PM, Robert Munteanu  wrote:
> Hi,
>
> I tried to build the jaas module as of r1709963 . The build fails due
> to the animal-sniffer-maven-plugin:
>
> [INFO] Checking unresolved references to
> org.codehaus.mojo.signature:java15:1.0
> [ERROR]
> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac
> he/felix/jaas/internal/ConfigSpiOsgi.java:117: Undefined reference:
> void javax.security.auth.login.ConfigurationSpi.()
> [ERROR]
> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac
> he/felix/jaas/internal/ConfigSpiOsgi.java:147: Undefined reference:
> javax.security.auth.login.Configuration
> javax.security.auth.login.Configuration.getInstance(String,
> javax.security.auth.login.Configuration.Parameters, String)
>
> [ERROR]/home/robert/Documents/sources/apache/felix/jaas/src/main/java/o
> rg/apache/felix/jaas/internal/ConfigSpiOsgi.java:568: Undefined
> reference: Object[] java.util.Arrays.copyOf(Object[], int)
>
> I added the felix.java.version property with value 6 to the pom, and
> this allowed the build to progress. However, the Pax-Exam tests all
> fail, and the root error seems to be:
>
> ERROR: Bundle org.apache.felix.jaas.sample1 [21] Error starting
> file:/tmp/1445505936570-0/bundles/org.apache.felix.jaas.sample1_0.jar
>  (org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: mis
> sing requirement [21.0] osgi.wiring.package;
> (osgi.wiring.package=javax.security.auth))
>
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: missi
> ng requirement [21.0] osgi.wiring.package;
> (osgi.wiring.package=javax.security.auth)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLe
> velImpl.java:295)
> at java.lang.Thread.run(Thread.java:745)
>
> Is there anything more I should look into or is this a bug?
>
> Thanks,
>
> Robert
>

Re: git?

[Benson Margulies]

There is a relatively standard Apache workflow that handles GH PR's.
The committer merges the PR and pushes it, editing a comment to say
'closes #nnn" and the PR gets closed.


On Sun, Oct 25, 2015 at 12:51 PM, David Jencks  wrote:
> While working on bnd and OSGI at github I’ve become quite attached to the 
> triangular workflow model.  (cf 
> https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows
>  
> )
>  I probably should know already, but does anyone know how practical it is to 
> do this with apache git and developer branches at github?
>
> I don’t know if apache git is at version 2.5 yet, but from the above link it 
> looks like the new worktree feature may provide an alternate solution to the 
> multiple-branches problem.
>
> david jencks
>
>> On Oct 25, 2015, at 12:12 PM, David Jencks  wrote:
>>
>> Hi,
>>
>> In the 12+ years I’ve been working on apache projects I can’t recall any 
>> time when I’ve wanted to simultaneously check out different branches of 
>> modules of the same top level project.  Therefore, unless anyone has actual 
>> contrary experience, I’d be in favor of trying a single git repo and 
>> refining it into multiple repos if we discover problems in real life use.  
>> (I have wanted to check out different branches of the same project 
>> simultaneously, but with git this is not helped by more repos).
>>
>> thanks
>> david jencks
>>
>>> On Oct 25, 2015, at 2:47 AM, Christian Schneider  
>>> wrote:
>>>
>>> I am not sure if one git repo for everything would be a good idea. The main 
>>> reason is that in git (unlike in subversion) each branch and tag you do 
>>> contains all the other unrelated projects too.
>>> I think it would also be quite difficult to checkout a state of the repo 
>>> where you need bundle A in branch A1 and bundle B in branch B2. Probably 
>>> this would mean that you need to checkout two instances of the repo
>>> to have both branches visisble at the same time. You would then also have 
>>> to be really careful to not pick a project from the wrong checkout as it 
>>> would be in kind of an undefined state there.
>>>
>>> The other solution of having one git repo per bundle also seems to be quite 
>>> difficult to manage as you need to checkout and sync every such checkout in 
>>> the correct way. I have seen a project that does this at a customer and it 
>>> is not very easy to work in this structure.
>>>
>>> In the Aries project we went for kind of a compromise.
>>>
>>> We aim for releases by subproject. So each subproject can go into one git 
>>> repo.
>>> The advantage is that each tag in git really covers the whole subproject. 
>>> So from the git side this is natural.
>>>
>>> The downside is of course that in many cases bundles are released that did 
>>> not change at all.
>>> We make sure the package versions are done with semantic versioning.  So 
>>> from the OSGi point of view the versioning
>>> is still working as before.
>>>
>>> At the moment we have not yet done the migration to git but it is planned. 
>>> We are currently moving each subproject to the release by subproject model 
>>> gradually.
>>> Theoretically we can then move each subproject to git independently. I am 
>>> not sure though how to move the change history over in that case.
>>> In any case the Aries JPA project is the first one that is fully converted 
>>> to the release by subproject model if you want to take a look.
>>> https://github.com/apache/aries/tree/trunk/jpa
>>>
>>> Christian
>>>
>>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
 On Sat, Oct 24, 2015 at 4:21 PM, David Jencks  
 wrote:
> I like having several felix subprojects open in one eclipse instance at 
> once, which the current svn structure facilitates.  Having just one git 
> svn rebase to run is nice.  Is there a way to stitch together  several 
> smaller git repos that would work similarly?  Not knowing how to do this, 
> I am starting to lean towards one big repo.
 Well, there are git submodules. But I hate to take everyone into that
 rabbit hole. I think we should aim to start with one big repo and
 assume we can tame the maven-release-plugin to start with.


> FWIW, I’m hoping to move DS onto a gradle based build soon.
>
> thanks
> david jencks
>
>> On Oct 24, 2015, at 2:51 PM, Benson Margulies  
>> wrote:
>>
>> Greeting, Marcel,
>>
>> It's not my intention to try to talk anyone into changing how they
>> release anything. For the things that are built with Maven, it's my
>> preference to avoid exercising the maven-release-plugin's feature of
>> handling multiple released items in a repo, but it's just a
>> preference. If the acceptable compromise is to have less repos than
>> releasable items (possibly as few as one repo), I'd personally rather
>> do that than not mo

[GitHub] felix pull request: FELIX-5074, make compatible with bndlib 3.0

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/38


---
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.
---

[jira] [Resolved] (FELIX-5074) Using org.apache.felix.scr.bnd together with maven-bundle-plugin leads to using the wrong bnd version

[Pierre De Rop (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop resolved FELIX-5074.
--
   Resolution: Fixed
Fix Version/s: scr bnd plugin 1.5.0

Applied the patch (thanks Konrad).

> Using org.apache.felix.scr.bnd together with maven-bundle-plugin leads to 
> using the wrong bnd version
> -
>
> Key: FELIX-5074
> URL: https://issues.apache.org/jira/browse/FELIX-5074
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr bnd plugin 1.4.0
>Reporter: Konrad Windszus
>Assignee: Pierre De Rop
> Fix For: scr bnd plugin 1.5.0
>
> Attachments: pom.xml
>
>
> If I have a POM with a plugin configuration like this
> {code}
> 
>   org.apache.felix
>   maven-bundle-plugin
>   3.0.0
>   true
>   
> 
> 
> 
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=target/classes
> 
>   
>   
>   
>
>  org.apache.felix
>  org.apache.felix.scr.bnd
>  1.4.0
>
>  
>  
> {code}
> Unfortunately {{org.apache.felix.scr.bnd}} depends on 
> {{biz.aQute.bnd:bndlib:jar:2.1.0}}. Therefore the classpath of 
> maven-bundle-plugin looks like this:
> {code}
> [DEBUG] Populating class realm 
> plugin>org.apache.felix:maven-bundle-plugin:3.0.0
> [DEBUG]   Included: org.apache.felix:maven-bundle-plugin:jar:3.0.0
> [DEBUG]   Included: org.apache.felix:org.apache.felix.scr.bnd:jar:1.4.0
> [DEBUG]   Included: biz.aQute.bnd:bndlib:jar:2.1.0
> [DEBUG]   Included: org.osgi:org.osgi.core:jar:4.3.1
> [DEBUG]   Included: biz.aQute.bnd:biz.aQute.bndlib:jar:3.0.0
> [DEBUG]   Included: 
> org.apache.felix:org.apache.felix.bundlerepository:jar:1.6.6
> [DEBUG]   Included: org.easymock:easymock:jar:2.5.2
> [DEBUG]   Included: org.apache.felix:org.apache.felix.utils:jar:1.6.0
> [DEBUG]   Included: org.osgi:org.osgi.compendium:jar:4.2.0
> [DEBUG]   Included: org.slf4j:slf4j-jdk14:jar:1.5.6
> [DEBUG]   Included: org.slf4j:slf4j-api:jar:1.5.6
> [DEBUG]   Included: org.slf4j:jcl-over-slf4j:jar:1.5.6
> [DEBUG]   Included: org.apache.maven.reporting:maven-reporting-api:jar:2.2.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-logging-api:jar:1.1
> [DEBUG]   Included: junit:junit:jar:4.11
> [DEBUG]   Included: org.hamcrest:hamcrest-core:jar:1.3
> [DEBUG]   Included: commons-cli:commons-cli:jar:1.2
> [DEBUG]   Included: 
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4
> [DEBUG]   Included: backport-util-concurrent:backport-util-concurrent:jar:3.1
> [DEBUG]   Included: org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
> [DEBUG]   Included: org.sonatype.plexus:plexus-cipher:jar:1.4
> [DEBUG]   Included: org.apache.maven:maven-archiver:jar:2.5
> [DEBUG]   Included: org.codehaus.plexus:plexus-archiver:jar:2.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-io:jar:2.0.2
> [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.15
> [DEBUG]   Included: org.apache.maven.shared:maven-dependency-tree:jar:2.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-component-annotations:jar:1.5.5
> [DEBUG]   Included: org.eclipse.aether:aether-util:jar:0.9.0.M2
> [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0.10
> [DEBUG]   Included: org.sonatype.plexus:plexus-build-api:jar:0.0.7
> [DEBUG]   Included: org.apache.maven.doxia:doxia-sink-api:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-site-renderer:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-core:jar:1.0
> [DEBUG]   Included: org.codehaus.plexus:plexus-i18n:jar:1.0-beta-7
> [DEBUG]   Included: org.codehaus.plexus:plexus-velocity:jar:1.1.7
> [DEBUG]   Included: org.apache.velocity:velocity:jar:1.5
> [DEBUG]   Included: commons-lang:commons-lang:jar:2.1
> [DEBUG]   Included: oro:oro:jar:2.0.8
> [DEBUG]   Included: org.apache.maven.doxia:doxia-decoration-model:jar:1.0
> [DEBUG]   Included: commons-collections:commons-collections:jar:3.2
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-apt:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-fml:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-xdoc:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-xhtml:jar:1.0
> [DEBUG]   Excluded: org.apache.maven:maven-core:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-settings:jar:2.2.0
> [DEBUG]   Excluded: 
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-profile:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-model:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-artifact:jar:2.2.0
> [DEBUG]   Excluded: 
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG]   Excluded: org.apache.maven:maven-repository-metadata:jar:2

[jira] [Commented] (FELIX-5074) Using org.apache.felix.scr.bnd together with maven-bundle-plugin leads to using the wrong bnd version

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14973469#comment-14973469
 ] 

ASF GitHub Bot commented on FELIX-5074:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/38


> Using org.apache.felix.scr.bnd together with maven-bundle-plugin leads to 
> using the wrong bnd version
> -
>
> Key: FELIX-5074
> URL: https://issues.apache.org/jira/browse/FELIX-5074
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr bnd plugin 1.4.0
>Reporter: Konrad Windszus
>Assignee: Pierre De Rop
> Attachments: pom.xml
>
>
> If I have a POM with a plugin configuration like this
> {code}
> 
>   org.apache.felix
>   maven-bundle-plugin
>   3.0.0
>   true
>   
> 
> 
> 
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=target/classes
> 
>   
>   
>   
>
>  org.apache.felix
>  org.apache.felix.scr.bnd
>  1.4.0
>
>  
>  
> {code}
> Unfortunately {{org.apache.felix.scr.bnd}} depends on 
> {{biz.aQute.bnd:bndlib:jar:2.1.0}}. Therefore the classpath of 
> maven-bundle-plugin looks like this:
> {code}
> [DEBUG] Populating class realm 
> plugin>org.apache.felix:maven-bundle-plugin:3.0.0
> [DEBUG]   Included: org.apache.felix:maven-bundle-plugin:jar:3.0.0
> [DEBUG]   Included: org.apache.felix:org.apache.felix.scr.bnd:jar:1.4.0
> [DEBUG]   Included: biz.aQute.bnd:bndlib:jar:2.1.0
> [DEBUG]   Included: org.osgi:org.osgi.core:jar:4.3.1
> [DEBUG]   Included: biz.aQute.bnd:biz.aQute.bndlib:jar:3.0.0
> [DEBUG]   Included: 
> org.apache.felix:org.apache.felix.bundlerepository:jar:1.6.6
> [DEBUG]   Included: org.easymock:easymock:jar:2.5.2
> [DEBUG]   Included: org.apache.felix:org.apache.felix.utils:jar:1.6.0
> [DEBUG]   Included: org.osgi:org.osgi.compendium:jar:4.2.0
> [DEBUG]   Included: org.slf4j:slf4j-jdk14:jar:1.5.6
> [DEBUG]   Included: org.slf4j:slf4j-api:jar:1.5.6
> [DEBUG]   Included: org.slf4j:jcl-over-slf4j:jar:1.5.6
> [DEBUG]   Included: org.apache.maven.reporting:maven-reporting-api:jar:2.2.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-logging-api:jar:1.1
> [DEBUG]   Included: junit:junit:jar:4.11
> [DEBUG]   Included: org.hamcrest:hamcrest-core:jar:1.3
> [DEBUG]   Included: commons-cli:commons-cli:jar:1.2
> [DEBUG]   Included: 
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4
> [DEBUG]   Included: backport-util-concurrent:backport-util-concurrent:jar:3.1
> [DEBUG]   Included: org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
> [DEBUG]   Included: org.sonatype.plexus:plexus-cipher:jar:1.4
> [DEBUG]   Included: org.apache.maven:maven-archiver:jar:2.5
> [DEBUG]   Included: org.codehaus.plexus:plexus-archiver:jar:2.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-io:jar:2.0.2
> [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.15
> [DEBUG]   Included: org.apache.maven.shared:maven-dependency-tree:jar:2.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-component-annotations:jar:1.5.5
> [DEBUG]   Included: org.eclipse.aether:aether-util:jar:0.9.0.M2
> [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0.10
> [DEBUG]   Included: org.sonatype.plexus:plexus-build-api:jar:0.0.7
> [DEBUG]   Included: org.apache.maven.doxia:doxia-sink-api:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-site-renderer:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-core:jar:1.0
> [DEBUG]   Included: org.codehaus.plexus:plexus-i18n:jar:1.0-beta-7
> [DEBUG]   Included: org.codehaus.plexus:plexus-velocity:jar:1.1.7
> [DEBUG]   Included: org.apache.velocity:velocity:jar:1.5
> [DEBUG]   Included: commons-lang:commons-lang:jar:2.1
> [DEBUG]   Included: oro:oro:jar:2.0.8
> [DEBUG]   Included: org.apache.maven.doxia:doxia-decoration-model:jar:1.0
> [DEBUG]   Included: commons-collections:commons-collections:jar:3.2
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-apt:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-fml:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-xdoc:jar:1.0
> [DEBUG]   Included: org.apache.maven.doxia:doxia-module-xhtml:jar:1.0
> [DEBUG]   Excluded: org.apache.maven:maven-core:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-settings:jar:2.2.0
> [DEBUG]   Excluded: 
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-profile:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-model:jar:2.2.0
> [DEBUG]   Excluded: org.apache.maven:maven-artifact:jar:2.2.0
> [DEBUG]   Excluded: 
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG]   Excluded: org.apache.maven:maven-repository-metadata:j

Re: git?

[David Jencks]

While working on bnd and OSGI at github I’ve become quite attached to the 
triangular workflow model.  (cf 
https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows
 
)
 I probably should know already, but does anyone know how practical it is to do 
this with apache git and developer branches at github?

I don’t know if apache git is at version 2.5 yet, but from the above link it 
looks like the new worktree feature may provide an alternate solution to the 
multiple-branches problem.

david jencks

> On Oct 25, 2015, at 12:12 PM, David Jencks  wrote:
> 
> Hi,
> 
> In the 12+ years I’ve been working on apache projects I can’t recall any time 
> when I’ve wanted to simultaneously check out different branches of modules of 
> the same top level project.  Therefore, unless anyone has actual contrary 
> experience, I’d be in favor of trying a single git repo and refining it into 
> multiple repos if we discover problems in real life use.  (I have wanted to 
> check out different branches of the same project simultaneously, but with git 
> this is not helped by more repos).
> 
> thanks
> david jencks
> 
>> On Oct 25, 2015, at 2:47 AM, Christian Schneider  
>> wrote:
>> 
>> I am not sure if one git repo for everything would be a good idea. The main 
>> reason is that in git (unlike in subversion) each branch and tag you do 
>> contains all the other unrelated projects too.
>> I think it would also be quite difficult to checkout a state of the repo 
>> where you need bundle A in branch A1 and bundle B in branch B2. Probably 
>> this would mean that you need to checkout two instances of the repo
>> to have both branches visisble at the same time. You would then also have to 
>> be really careful to not pick a project from the wrong checkout as it would 
>> be in kind of an undefined state there.
>> 
>> The other solution of having one git repo per bundle also seems to be quite 
>> difficult to manage as you need to checkout and sync every such checkout in 
>> the correct way. I have seen a project that does this at a customer and it 
>> is not very easy to work in this structure.
>> 
>> In the Aries project we went for kind of a compromise.
>> 
>> We aim for releases by subproject. So each subproject can go into one git 
>> repo.
>> The advantage is that each tag in git really covers the whole subproject. So 
>> from the git side this is natural.
>> 
>> The downside is of course that in many cases bundles are released that did 
>> not change at all.
>> We make sure the package versions are done with semantic versioning.  So 
>> from the OSGi point of view the versioning
>> is still working as before.
>> 
>> At the moment we have not yet done the migration to git but it is planned. 
>> We are currently moving each subproject to the release by subproject model 
>> gradually.
>> Theoretically we can then move each subproject to git independently. I am 
>> not sure though how to move the change history over in that case.
>> In any case the Aries JPA project is the first one that is fully converted 
>> to the release by subproject model if you want to take a look.
>> https://github.com/apache/aries/tree/trunk/jpa
>> 
>> Christian
>> 
>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks  
>>> wrote:
 I like having several felix subprojects open in one eclipse instance at 
 once, which the current svn structure facilitates.  Having just one git 
 svn rebase to run is nice.  Is there a way to stitch together  several 
 smaller git repos that would work similarly?  Not knowing how to do this, 
 I am starting to lean towards one big repo.
>>> Well, there are git submodules. But I hate to take everyone into that
>>> rabbit hole. I think we should aim to start with one big repo and
>>> assume we can tame the maven-release-plugin to start with.
>>> 
>>> 
 FWIW, I’m hoping to move DS onto a gradle based build soon.
 
 thanks
 david jencks
 
> On Oct 24, 2015, at 2:51 PM, Benson Margulies  
> wrote:
> 
> Greeting, Marcel,
> 
> It's not my intention to try to talk anyone into changing how they
> release anything. For the things that are built with Maven, it's my
> preference to avoid exercising the maven-release-plugin's feature of
> handling multiple released items in a repo, but it's just a
> preference. If the acceptable compromise is to have less repos than
> releasable items (possibly as few as one repo), I'd personally rather
> do that than not move to git at all.
> 
> regards,
> 
> benson
> 
> 
> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>  wrote:
>> On 24 October 2015 at 11:36:03, Benson Margulies 
>> (ben...@basistech.com(mailto:ben...@basistech.com)) wrote:
>> 
 So I would definitely argue against gettin

Re: git?

[David Jencks]

Hi,

In the 12+ years I’ve been working on apache projects I can’t recall any time 
when I’ve wanted to simultaneously check out different branches of modules of 
the same top level project.  Therefore, unless anyone has actual contrary 
experience, I’d be in favor of trying a single git repo and refining it into 
multiple repos if we discover problems in real life use.  (I have wanted to 
check out different branches of the same project simultaneously, but with git 
this is not helped by more repos).

thanks
david jencks

> On Oct 25, 2015, at 2:47 AM, Christian Schneider  
> wrote:
> 
> I am not sure if one git repo for everything would be a good idea. The main 
> reason is that in git (unlike in subversion) each branch and tag you do 
> contains all the other unrelated projects too.
> I think it would also be quite difficult to checkout a state of the repo 
> where you need bundle A in branch A1 and bundle B in branch B2. Probably this 
> would mean that you need to checkout two instances of the repo
> to have both branches visisble at the same time. You would then also have to 
> be really careful to not pick a project from the wrong checkout as it would 
> be in kind of an undefined state there.
> 
> The other solution of having one git repo per bundle also seems to be quite 
> difficult to manage as you need to checkout and sync every such checkout in 
> the correct way. I have seen a project that does this at a customer and it is 
> not very easy to work in this structure.
> 
> In the Aries project we went for kind of a compromise.
> 
> We aim for releases by subproject. So each subproject can go into one git 
> repo.
> The advantage is that each tag in git really covers the whole subproject. So 
> from the git side this is natural.
> 
> The downside is of course that in many cases bundles are released that did 
> not change at all.
> We make sure the package versions are done with semantic versioning.  So from 
> the OSGi point of view the versioning
> is still working as before.
> 
> At the moment we have not yet done the migration to git but it is planned. We 
> are currently moving each subproject to the release by subproject model 
> gradually.
> Theoretically we can then move each subproject to git independently. I am not 
> sure though how to move the change history over in that case.
> In any case the Aries JPA project is the first one that is fully converted to 
> the release by subproject model if you want to take a look.
> https://github.com/apache/aries/tree/trunk/jpa
> 
> Christian
> 
> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks  
>> wrote:
>>> I like having several felix subprojects open in one eclipse instance at 
>>> once, which the current svn structure facilitates.  Having just one git svn 
>>> rebase to run is nice.  Is there a way to stitch together  several smaller 
>>> git repos that would work similarly?  Not knowing how to do this, I am 
>>> starting to lean towards one big repo.
>> Well, there are git submodules. But I hate to take everyone into that
>> rabbit hole. I think we should aim to start with one big repo and
>> assume we can tame the maven-release-plugin to start with.
>> 
>> 
>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>> 
>>> thanks
>>> david jencks
>>> 
 On Oct 24, 2015, at 2:51 PM, Benson Margulies  wrote:
 
 Greeting, Marcel,
 
 It's not my intention to try to talk anyone into changing how they
 release anything. For the things that are built with Maven, it's my
 preference to avoid exercising the maven-release-plugin's feature of
 handling multiple released items in a repo, but it's just a
 preference. If the acceptable compromise is to have less repos than
 releasable items (possibly as few as one repo), I'd personally rather
 do that than not move to git at all.
 
 regards,
 
 benson
 
 
 On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
  wrote:
> On 24 October 2015 at 11:36:03, Benson Margulies 
> (ben...@basistech.com(mailto:ben...@basistech.com)) wrote:
> 
>>> So I would definitely argue against getting a Git repository per bundle.
>>> Per subproject sounds like the right granularity to me.
>> If a subproject is released all at once, then we're completely
>> agreeing. If not, then your preference means exercising the
>> occasionally squishy part of the release plugin; maybe it will get
>> fixed once and for all.
> So for the dependency manager we reasoned as follows:
> 
> 1) When talking about releases within Apache, we are talking about source 
> code. Releasing that a subproject at a time makes sense to me as the 
> code, even if it ends up in different bundles, clearly belongs together.
> 
> 2) Binary releases are a matter of convenience and “what is convenient” 
> depends a lot on where you’re coming from. A lot of people would argue

Re: git?

[Christian Schneider]

I am not sure if one git repo for everything would be a good idea. The 
main reason is that in git (unlike in subversion) each branch and tag 
you do contains all the other unrelated projects too.
I think it would also be quite difficult to checkout a state of the repo 
where you need bundle A in branch A1 and bundle B in branch B2. Probably 
this would mean that you need to checkout two instances of the repo
to have both branches visisble at the same time. You would then also 
have to be really careful to not pick a project from the wrong checkout 
as it would be in kind of an undefined state there.


The other solution of having one git repo per bundle also seems to be 
quite difficult to manage as you need to checkout and sync every such 
checkout in the correct way. I have seen a project that does this at a 
customer and it is not very easy to work in this structure.


In the Aries project we went for kind of a compromise.

We aim for releases by subproject. So each subproject can go into one 
git repo.
The advantage is that each tag in git really covers the whole 
subproject. So from the git side this is natural.


The downside is of course that in many cases bundles are released that 
did not change at all.
We make sure the package versions are done with semantic versioning.  So 
from the OSGi point of view the versioning

is still working as before.

At the moment we have not yet done the migration to git but it is 
planned. We are currently moving each subproject to the release by 
subproject model gradually.
Theoretically we can then move each subproject to git independently. I 
am not sure though how to move the change history over in that case.
In any case the Aries JPA project is the first one that is fully 
converted to the release by subproject model if you want to take a look.

https://github.com/apache/aries/tree/trunk/jpa

Christian

Am 24.10.2015 um 23:32 schrieb Benson Margulies:

On Sat, Oct 24, 2015 at 4:21 PM, David Jencks  wrote:

I like having several felix subprojects open in one eclipse instance at once, 
which the current svn structure facilitates.  Having just one git svn rebase to 
run is nice.  Is there a way to stitch together  several smaller git repos that 
would work similarly?  Not knowing how to do this, I am starting to lean 
towards one big repo.

Well, there are git submodules. But I hate to take everyone into that
rabbit hole. I think we should aim to start with one big repo and
assume we can tame the maven-release-plugin to start with.



FWIW, I’m hoping to move DS onto a gradle based build soon.

thanks
david jencks


On Oct 24, 2015, at 2:51 PM, Benson Margulies  wrote:

Greeting, Marcel,

It's not my intention to try to talk anyone into changing how they
release anything. For the things that are built with Maven, it's my
preference to avoid exercising the maven-release-plugin's feature of
handling multiple released items in a repo, but it's just a
preference. If the acceptable compromise is to have less repos than
releasable items (possibly as few as one repo), I'd personally rather
do that than not move to git at all.

regards,

benson


On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
 wrote:

On 24 October 2015 at 11:36:03, Benson Margulies 
(ben...@basistech.com(mailto:ben...@basistech.com)) wrote:


So I would definitely argue against getting a Git repository per bundle.
Per subproject sounds like the right granularity to me.

If a subproject is released all at once, then we're completely
agreeing. If not, then your preference means exercising the
occasionally squishy part of the release plugin; maybe it will get
fixed once and for all.

So for the dependency manager we reasoned as follows:

1) When talking about releases within Apache, we are talking about source code. 
Releasing that a subproject at a time makes sense to me as the code, even if it 
ends up in different bundles, clearly belongs together.

2) Binary releases are a matter of convenience and “what is convenient” depends 
a lot on where you’re coming from. A lot of people would argue that putting a 
binary in Maven is convenient, but there are definitely other options. The 
binary releases also don’t have to have a 1:1 mapping with the source, so we 
can have N bundles being put in Maven and other repositories all from the same 
source release.

Greetings, Marcel