Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Markus Tiede]

We'll investigate the possibility and track any progress here [1].

With best regards,
MarkusT

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=408311

On 17.05.2013 05:37, David M Williams wrote:

In investigating
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=407797_

we've seen there are two projects that use the older version of 
org.slf4j.api ... Code Recommenders and Jubula. Any chance you can 
"move up"?


And, we've found two projects that "provide" the old, incompatible 
logging fragment ch.qos.logback.slf4j 1.0.0.v20120123-1500, both with 
m2e in the name :) ... any chance you can provide more specific input, 
that includes only the most recent?


My suspicion is that it is (mostly) the old fragments that are 
problematic ... That is, p2 sees them as "valid solutions" to the 
constraints its given ... but, it is not a satisfactory solution to 
the humans using the system. One "cure" might be to make sure only the 
most
recent fragment is available in the repositories that you "provide" as 
input to the common repository.


See the bug for suggestions on how to do that ... how to provide more 
specific versions of stuff, without literally removing old stuff. 
(released repositories are supposed to be immutable ... but, you do 
not need to "provide" your whole entire composite repo as input to the 
common repo ... only the most recent, specific things that you are 
willing to have end up there).


HTH





From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org,
Date: 05/16/2013 01:03 PM
Subject: [cross-project-issues-dev] Code Recommenders and other users 
oforg.slf4j.api

Sent by: cross-project-issues-dev-boun...@eclipse.org




If you use "org.slf4j.api" please see bug 407797.
_
__https://bugs.eclipse.org/bugs/show_bug.cgi?id=407797_

There's several complicated issues going on in that bug, but one cure 
might be if everyone "used the latest" version of org.slf4j.api 
(1.7.2, instead of 1.6.4).


From the b3 aggregator log, it appears that Code Recommenders is the 
one "pulling in" version 1.6.4.


Is that on purpose? That is, do you purposely constrain/include that 
older version? Any chance to move up to the latest?


These loggers (and their fragments) are a case where having multiple 
versions in the repository can mess up other projects -- that is, 
things "work fine" if using your individual project repository ... 
but, not once one big repository tries to "satisfy everyone".


While there might be other bugs involved causing the fundamental 
problem, it seems that "using the latest" would be a quick, practical 
solution, here at RC1.


Please comment in the bug, or (anyone) make other suggestions ... but, 
it is something that needs to be solved.


If I don't hear anything soon, I may try a test run temporarily 
disabling Code Recommenders, just to test the hypothesis that it is 
the (only) source of these "conflicting" requirements.


Thanks,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi David,

> From the b3 aggregator log, it appears that Code Recommenders is the one
> "pulling in" version 1.6.4.
> 
> Is that on purpose? That is, do you purposely constrain/include that
> older version? Any chance to move up to the latest?

Sure. Will look into this straight away.

Andreas
-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Hudson Snapshot Instance OutOfMemoryError

[Stephan Leicht Vogt]

Hi

Our Scout RT Gerrit Job on the Hudson Sandbox fails with an OutOfMemoryError 
(https://hudson.eclipse.org/sandbox/job/eclipse.scout.rt/160/console):


#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 2147483656 bytes for Chunk::new. Out of 
swap space?
#
#  Internal Error (allocation.cpp:215), pid=32563, tid=2726484848
#  Error: Chunk::new
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 )
# An error report file with more information is saved as:
# 
/opt/users/hudsonbuild/.hudson/jobs/eclipse.scout.rt/workspace/hs_err_pid32563.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
[ERROR] Failure: hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel

What is the best way to reach a person which can solve this issue? Should I 
open a Bug?

Thanks for any insights
Stephan

---
Stephan Leicht Vogt
Senior Software Engineer

BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com



smime.p7s
Description: S/MIME cryptographic signature
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Hudson Snapshot Instance OutOfMemoryError

[Denis Roy]

On 05/17/2013 08:24 AM, Stephan Leicht Vogt wrote:


What is the best way to reach a person which can solve this issue? 
Should I open a Bug?


Something in your job was trying to allocate 2G of RAM .. That doesn't 
seem right to me.


A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 2147483656 bytes for Chunk::new. Out of 
swap space?
#
#  Internal Error (allocation.cpp:215), pid=27591, tid=2729401200
#  Error: Chunk::new
#



A bit of Googling leads me to believe we perhaps need to run Hudson on a 
newer JVM, as this seems to point to a memory leak.


Please file a bug against Eclipse Foundation > Community > Hudson.

Thanks
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi,

>> From the b3 aggregator log, it appears that Code Recommenders is the one
>> "pulling in" version 1.6.4.
>>
>> Is that on purpose? That is, do you purposely constrain/include that
>> older version? Any chance to move up to the latest?
> 
> Sure. Will look into this straight away.

made the move to org.slf4j.api 1.7.2:



Hope that fixes the problem. If not, please complain (again ;-)!

Andreas
-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[David M Williams]

Thanks for your quick cooperation ... I bet you will be happier with the 
newest version anyway ... at least I hope! 

Thanks again, 




From:   Andreas Sewe 
To: cross-project-issues-dev@eclipse.org, 
Cc: Marcel Bruch 
Date:   05/17/2013 01:50 PM
Subject:Re: [cross-project-issues-dev] Code Recommenders, Jubula, 
m2e-wtp and other users of org.slf4j.api and providers of 
ch.qos.logback.slf4j
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

>> From the b3 aggregator log, it appears that Code Recommenders is the 
one
>> "pulling in" version 1.6.4.
>>
>> Is that on purpose? That is, do you purposely constrain/include that
>> older version? Any chance to move up to the latest?
> 
> Sure. Will look into this straight away.

made the move to org.slf4j.api 1.7.2:



Hope that fixes the problem. If not, please complain (again ;-)!

Andreas
-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_
__
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi David,

> Thanks for your quick cooperation ... I bet you will be happier with the
> newest version anyway ... at least I hope!

I bet we won't notice the difference: log.error(..) is still the same as
always.

Anyway, can you just double-check [1] that the other, SLF4J related
plugins like ch.qos.logback.slf4j are also using the right version? Thanks.

Best regards,

Andreas

[1]


-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Libraty piggy-back CQs

[Wayne Beaton]

  
  
I believe that the Contribution Questionnaire page in the wiki [1]
answers this. If it is unclear, either take a crack at clarifying it
yourself or let me know I can take another run at it.

The short version is that you need CQ for any library that project
code uses directly. You do not require a CQ for any library that is
used indirectly via another Eclipse project. I spelled this out in
more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of
a library that project code uses. 

It doesn't matter where project code comes from. If a tool like
Xtext generates project code (i.e. code that goes into your source
code repository, or dynamically-generated code that gets distributed
in compiled form) that uses a library, this is considered a direct
reference.

HTH,

Wayne

[1]

http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire


On 05/17/2013 02:31 AM, Ed Willink
  wrote:

Hi
  Wayne
  
  
  Can you clarify the policy on library piggy-back CQs?
  
  
  For MDT/OCL we initially used Guava indirectly through Xtext and
  so might not need a PB CQ although we did raise one since Xtext
  auto-generates source code for us with direct calls to the
  Injector class. Subsequently we have some manually written code
  that exploits Guava too.
  
  
  Our PB CQ has not updated from version 10, although Guava in Orbit
  is charging along through 11, 12 with 14 on the horizon.
  
  
  Are we at fault through not raising more PB CQs? Do I
  misunderstand the policy? Is the policy inappropriate for major
  evolving libraries?
  
  
      Regards
  
  
      Ed Willink
  
  ___
  
  cross-project-issues-dev mailing list
  
  cross-project-issues-dev@eclipse.org
  
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  


-- 
  Wayne Beaton
  Director of Open Source Projects, The Eclipse Foundation
  Learn about Eclipse
Projects
  
  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews

[Wayne Beaton]

  
  
The contribution review tool is intended to assist a project in
identifying IP contributions that come through Bugzilla.

If your project is using Git and is pushing commits that are
correctly annotated with author information, then this tool will be
of no interest to you.

Its main value at this point is mostly historical for most projects.

I'll add a link to the IP Log generator from the project page.

HTH,

Wayne

On 05/17/2013 02:26 AM, Ed Willink
  wrote:


  
  Hi
  
  Found it. It's lurking on the left of 
  http://eclipse.org/projects/tools/ip_contribution_review.php,
  so if you ignore the rubbish from 
  http://eclipse.org/projects/tools/ip_contribution_review.php
  you get the good old review.
  
      Regards
  
          Ed Willink
  
  On 17/05/2013 07:18, Ed Willink wrote:
  

Hi

What has happened to the old (very good) IP tool?

It gave me a good auto-generated log for MDT/OCL that I could
easily review.

http://eclipse.org/projects/tools/ip_contribution_review.php
is hard to find (no link from portal or project page) and gives
me a list of over 600 bugs to review. No way. There have been
zero IP contributions so I expect to do the job in 10 minutes
not 10 hours.

If there really is a change in diligence then please threshold
it at resolution after Juno, since all pre-Juno bugs have been
IP logged and approved.

    Regards

        Ed Willink


On 26/04/2013 19:24, The Eclipse Foundation wrote:

  
  Kepler approaches. 
  
  I'm starting to get IP Log review requests for the upcoming
  release. In at least two cases, I'm pretty sure that the
  submitter thought that the release date was in May. To be
  clear, here are the dates:
  
  May 24/2013 - Deadline to submit IP Logs for Kepler releases
  June 5/2013 - PMC-approved Review materials submitted to EMO
  June 12/2013 - Kepler Uber Release review
  June 26/2013 - Kepler release
  
  The IP Logs are not due for another month. It's still a little
  early, but it's perfectly acceptable to submit your IP log for
  review in advance of the actual required-by date. Just keep in
  mind that the log needs to accurately reflect the content that
  you're releasing; if you anticipate receiving any
  contributions from folks who are not committers, it might be a
  good idea to hold off for a while.
  
  While I'm at it, I'd like to make a plea to everybody to please



try and honour the dates specified. There are a few
  projects that make a habit of submitting the required
  materials late; this causes a lot of stress for everybody
  involved. If you haven't started thinking about your IP Log
  and review documentation, now might be a good time to do so.
  
  I need to have you PMC-approved review documentation before
EOB on June 5/2013. You can either do what we've been
  doing for years and submit this information as a presentation,
  document, PDF, or whatever. Or you can just enter review
  information directly in the release record in the Project
  Management Infrastructure. A few of you have already started
  doing the latter; my sense is that it is an easy way to
  assemble and provide this information. Please let me know if
  you think otherwise, or if there is anything that we can do to
  improve it.
  
  The PMC approval part is important. Get it approved.
  This may take some time. Plan to engage your PMC at least a
  full week in advance of the June 5 deadline. PMC members,
  please make sure that the document is complete and that you
  are satisfied with its content before providing your approval.
  When I look at the extremely short (or non-existent) "outside
  contributions" sections on some IP logs, I grow concerned that
  some projects aren't doing enough to court the community and
  grow diversity.
  
  Please use the Release Review checklist to make sure that
  you've done all the necessary bits:
  
  
  http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist
  
  Note that this checklist has been around for a long time.
  There should be nothing new or surprising here.
  
  I've noticed that a lot of projects do not have plans
posted. This is an important and necessary part of the

Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[David M Williams]

Looks right to me ... but ... to be honest, I know a whole lot less about 
it than just about anyone else :) 
(e.g not sure you need "all three" fragments ... but, no idea how it is 
normally shipped/configured). 
So, I've passed on your question to the original bug, and added you to CC 
in case some of the people discussing it there have any comments. 
Bug 407797 - inconsistent mixture of org.slf4j.api and 
ch.qos.logback.slf4j 

Thanks again, 




From:   Andreas Sewe 
To: cross-project-issues-dev@eclipse.org, 
Date:   05/17/2013 02:07 PM
Subject:Re: [cross-project-issues-dev] Code Recommenders, Jubula, 
m2e-wtp and other users of org.slf4j.api and providers of 
ch.qos.logback.slf4j
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi David,

> Thanks for your quick cooperation ... I bet you will be happier with the
> newest version anyway ... at least I hope!

I bet we won't notice the difference: log.error(..) is still the same as
always.

Anyway, can you just double-check [1] that the other, SLF4J related
plugins like ch.qos.logback.slf4j are also using the right version? 
Thanks.

Best regards,

Andreas

[1]


-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_
__
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Libraty piggy-back CQs

[Ed Willink]

  
  
Hi

Thanks; that's clear but is hardly sensible. I have a handful of PB
CQs to raise and I suspect many other projects must do too.

Since we are strongly encouarged to track the latest Orbit version,
shouldn't there be an auto-PB CQ for any project that has a PB CQ
for an Orbit library?

Currently I see
20 Guava 10.x PB CQs
2 Guava 11.x PB CQs
0 Guava 12.x PB CQs
4 Guava 13.x PB CQs
0 Guava 14.x PB CQs

With M7 changing the preferred Guava release to 12 that makes for 20
out of 20 projects in breach of IP policy.

    Regards

        Ed Willink




On 17/05/2013 19:20, Wayne Beaton wrote:

  
  I believe that the Contribution Questionnaire page in the wiki [1]
  answers this. If it is unclear, either take a crack at clarifying
  it yourself or let me know I can take another run at it.
  
  The short version is that you need CQ for any library that project
  code uses directly. You do not require a CQ for any library that
  is used indirectly via another Eclipse project. I spelled this out
  in more detail on the wiki page.
  
  CQs are version-specific. You need a CQ for each version
  of a library that project code uses. 
  
  It doesn't matter where project code comes from. If a tool like
  Xtext generates project code (i.e. code that goes into your source
  code repository, or dynamically-generated code that gets
  distributed in compiled form) that uses a library, this is
  considered a direct reference.
  
  HTH,
  
  Wayne
  
  [1]
  
  http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire
  
  
  On 05/17/2013 02:31 AM, Ed Willink
wrote:
  
  Hi

Wayne 

Can you clarify the policy on library piggy-back CQs? 

For MDT/OCL we initially used Guava indirectly through Xtext and
so might not need a PB CQ although we did raise one since Xtext
auto-generates source code for us with direct calls to the
Injector class. Subsequently we have some manually written code
that exploits Guava too. 

Our PB CQ has not updated from version 10, although Guava in
Orbit is charging along through 11, 12 with 14 on the horizon. 

Are we at fault through not raising more PB CQs? Do I
misunderstand the policy? Is the policy inappropriate for major
evolving libraries? 

    Regards 

    Ed Willink 
___ 
cross-project-issues-dev mailing list 
cross-project-issues-dev@eclipse.org

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


  
  
  -- 
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

  
  
  
  ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

  
  
  
  No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date:
05/17/13


  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Libraty piggy-back CQs

[Wayne Beaton]

  
  
The issue is one of tracking who is using what third-party library.


Right now, the tools that I use to scan the downloads directory
almost do a good enough job to eliminate piggyback CQs altogether.
Almost. The problem is that the tool only detects libraries that are
actually distributed by the project. It works by file name alone. It
fails to detect libraries that are pulled in from Orbit, for
example.

I think that the solution is to scan bundles for references to
third-party libraries, but I'll need some p2 magic to sort that out,
I think. Bash just isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a
definitive list of dependencies (including bundle and package
imports?)

Of course, this doesn't help us if a project isn't distributing OSGi
bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink
  wrote:


  
  Hi
  
  Thanks; that's clear but is hardly sensible. I have a handful of
  PB CQs to raise and I suspect many other projects must do too.
  
  Since we are strongly encouarged to track the latest Orbit
  version, shouldn't there be an auto-PB CQ for any project that has
  a PB CQ for an Orbit library?
  
  Currently I see
  20 Guava 10.x PB CQs
  2 Guava 11.x PB CQs
  0 Guava 12.x PB CQs
  4 Guava 13.x PB CQs
  0 Guava 14.x PB CQs
  
  With M7 changing the preferred Guava release to 12 that makes for
  20 out of 20 projects in breach of IP policy.
  
      Regards
  
          Ed Willink
  
  
  
  
  On 17/05/2013 19:20, Wayne Beaton wrote:
  

I believe that the Contribution Questionnaire page in the wiki
[1] answers this. If it is unclear, either take a crack at
clarifying it yourself or let me know I can take another run at
it.

The short version is that you need CQ for any library that
project code uses directly. You do not require a CQ for any
library that is used indirectly via another Eclipse project. I
spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version
of a library that project code uses. 

It doesn't matter where project code comes from. If a tool like
Xtext generates project code (i.e. code that goes into your
source code repository, or dynamically-generated code that gets
distributed in compiled form) that uses a library, this is
considered a direct reference.

HTH,

Wayne

[1]

http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire


On 05/17/2013 02:31 AM, Ed Willink
  wrote:

Hi Wayne 
  
  Can you clarify the policy on library piggy-back CQs? 
  
  For MDT/OCL we initially used Guava indirectly through Xtext
  and so might not need a PB CQ although we did raise one since
  Xtext auto-generates source code for us with direct calls to
  the Injector class. Subsequently we have some manually written
  code that exploits Guava too. 
  
  Our PB CQ has not updated from version 10, although Guava in
  Orbit is charging along through 11, 12 with 14 on the horizon.
  
  
  Are we at fault through not raising more PB CQs? Do I
  misunderstand the policy? Is the policy inappropriate for
  major evolving libraries? 
  
      Regards 
  
      Ed Willink 
  ___ 
  cross-project-issues-dev mailing list 
  cross-project-issues-dev@eclipse.org
  
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  


-- 
  Wayne Beaton
  Director of Open Source Projects, The Eclipse Foundation
  Learn about Eclipse Projects
  



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




No virus
  found in this message.
  Checked by AVG - www.avg.com
  Version: 2013.0.3336 / Virus Database: 3162/6332 - Release
  Date: 05/17/13
  
  
  
  
  
  ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
  Wayne Beaton
  Director of Open Source Projects, The Eclipse Foundation
   

Re: [cross-project-issues-dev] Libraty piggy-back CQs

[Thomas Watson]

Also using Import-Package allows for provider substitution.  You don't
really know who the provider of the package dependency is by looking at a
bundle manifest in isolation.

Tom





From:   Wayne Beaton 
To: cross-project-issues-dev@eclipse.org,
Date:   05/17/2013 02:06 PM
Subject:Re: [cross-project-issues-dev] Libraty piggy-back CQs
Sent by:cross-project-issues-dev-boun...@eclipse.org



The issue is one of tracking who is using what third-party library.

Right now, the tools that I use to scan the downloads directory almost do a
good enough job to eliminate piggyback CQs altogether. Almost. The problem
is that the tool only detects libraries that are actually distributed by
the project. It works by file name alone. It fails to detect libraries that
are pulled in from Orbit, for example.

I think that the solution is to scan bundles for references to third-party
libraries, but I'll need some p2 magic to sort that out, I think. Bash just
isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a
definitive list of dependencies (including bundle and package imports?)

Of course, this doesn't help us if a project isn't distributing OSGi
bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink wrote:
  Hi

  Thanks; that's clear but is hardly sensible. I have a handful of PB
  CQs to raise and I suspect many other projects must do too.

  Since we are strongly encouarged to track the latest Orbit version,
  shouldn't there be an auto-PB CQ for any project that has a PB CQ for
  an Orbit library?

  Currently I see
  20 Guava 10.x PB CQs
  2 Guava 11.x PB CQs
  0 Guava 12.x PB CQs
  4 Guava 13.x PB CQs
  0 Guava 14.x PB CQs

  With M7 changing the preferred Guava release to 12 that makes for 20
  out of 20 projects in breach of IP policy.

  Regards

  Ed Willink




  On 17/05/2013 19:20, Wayne Beaton wrote:
I believe that the Contribution Questionnaire page in the wiki
[1] answers this. If it is unclear, either take a crack at
clarifying it yourself or let me know I can take another run at
it.

The short version is that you need CQ for any library that
project code uses directly. You do not require a CQ for any
library that is used indirectly via another Eclipse project. I
spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a
library that project code uses.

It doesn't matter where project code comes from. If a tool like
Xtext generates project code (i.e. code that goes into your
source code repository, or dynamically-generated code that gets
distributed in compiled form) that uses a library, this is
considered a direct reference.

HTH,

Wayne

[1]

http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire


On 05/17/2013 02:31 AM, Ed Willink wrote:
  Hi Wayne

  Can you clarify the policy on library piggy-back CQs?

  For MDT/OCL we initially used Guava indirectly through
  Xtext and so might not need a PB CQ although we did raise
  one since Xtext auto-generates source code for us with
  direct calls to the Injector class. Subsequently we have
  some manually written code that exploits Guava too.

  Our PB CQ has not updated from version 10, although Guava
  in Orbit is charging along through 11, 12 with 14 on the
  horizon.

  Are we at fault through not raising more PB CQs? Do I
  misunderstand the policy? Is the policy inappropriate for
  major evolving libraries?

  Regards

  Ed Willink
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev






No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release
Date: 05/17/13





  ___
  cros

Re: [cross-project-issues-dev] Libraty piggy-back CQs

[Wayne Beaton]

  
  
We may also be able to do something with Maven build logs.

Wayne

On 05/17/2013 03:20 PM, Thomas Watson
  wrote:


  Also using Import-Package
  allows for provider substitution.  You don't really know who
  the provider of the package dependency is by looking at a
  bundle manifest in isolation.

  Tom
  


Wayne Beaton ---05/17/2013 02:06:35
  PM---The issue is one of tracking who is using what
  third-party library. Right now, the tools that I use

From: Wayne Beaton
  
To: cross-project-issues-dev@eclipse.org,

Date: 05/17/2013 02:06 PM
Subject: Re: [cross-project-issues-dev]
  Libraty piggy-back CQs
Sent by: cross-project-issues-dev-boun...@eclipse.org
  
  
  
  
  The issue is one of tracking who is
using what third-party library. 

Right now, the tools that I use to scan the downloads directory
almost do a good enough job to eliminate piggyback CQs
altogether. Almost. The problem is that the tool only detects
libraries that are actually distributed by the project. It works
by file name alone. It fails to detect libraries that are pulled
in from Orbit, for example.

I think that the solution is to scan bundles for references to
third-party libraries, but I'll need some p2 magic to sort that
out, I think. Bash just isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for
a definitive list of dependencies (including bundle and package
imports?)

Of course, this doesn't help us if a project isn't distributing
OSGi bundles...

Wayne
  
  On 05/17/2013 02:35 PM, Ed Willink
wrote:
  
Hi
  
  Thanks; that's clear but is hardly sensible. I have a handful
  of PB CQs to raise and I suspect many other projects must do
  too.
  
  Since we are strongly encouarged to track the latest Orbit
  version, shouldn't there be an auto-PB CQ for any project that
  has a PB CQ for an Orbit library?
  
  Currently I see
  20 Guava 10.x PB CQs
  2 Guava 11.x PB CQs
  0 Guava 12.x PB CQs
  4 Guava 13.x PB CQs
  0 Guava 14.x PB CQs
  
  With M7 changing the preferred Guava release to 12 that makes
  for 20 out of 20 projects in breach of IP policy.
  
     Regards
  
         Ed Willink
  
  
  
  
  On 17/05/2013 19:20, Wayne Beaton wrote: 

  I believe that the Contribution
Questionnaire page in the wiki [1] answers this. If it is
unclear, either take a crack at clarifying it yourself or
let me know I can take another run at it.

The short version is that you need CQ for any library that
project code uses directly. You do not require a CQ for any
library that is used indirectly via another Eclipse project.
I spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a
library that project code uses. 

It doesn't matter where project code comes from. If a tool
like Xtext generates project code (i.e. code that goes into
your source code repository, or dynamically-generated code
that gets distributed in compiled form) that uses a library,
this is considered a direct reference.

HTH,

Wayne

[1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire
  
  On 05/17/2013 02:31 AM, Ed Willink
wrote:
  
Hi Wayne 
  
  Can you clarify the policy on library piggy-back CQs? 
  
  For MDT/OCL we initially used Guava indirectly through
  Xtext and so might not need a PB CQ although we did raise
  one since Xtext auto-generates source code for us with
  direct calls to the Injector class. Subsequently we have
  some manually written code that exploits Guava too. 
  
  Our PB CQ has not updated from version 10, although Guava
  in Orbit is charging along through 11, 12 with 14 on the
  horizon. 
  
  Are we at fault through not raising more PB CQs? Do I
  misunderstand the policy? Is the policy inappropriate for
  major evolving libraries? 
  
     Regards