I don't want to argue more about this. I don't agree, but I can do it
the requested way. I hope after the change, there will be no additional
objections. You can see that I was waiting 2 months for LSARC and I
presented package structure as part of the LSARC review. The LSARC is
over and closed
Brian Utterback wrote:
>
>
> Petr Slechta wrote:
>
>>> /usr/share/lib/java/
>> My personal opinion is that sharing all jar libraries is not good
>> idea. If every application has its own copies of jars then it is
>> independent. (Uninstallation of other application cannot brake it.)
>> Jar files
Hello,
please see my comments...
Petr
Jim Walker wrote:
> I would like some clarification on jar file porting for
> future arc cases.
>
> findbugs plans to integrate the following project private
> jar files.
>
> 163 f none usr/share/lib/java/findbugs/asm-analysis-3.1.jar
> 164 f none usr/share/
Petr Slechta writes:
> OK, if everything should be compiled (even if there are projects in SFW
> that do not do it), should I compile the libraries as part of findbugs
> project, or should I create separate project for each library (or set of
> libraries)? Like:
I see no reason that the existin
Petr Slechta wrote:
> And I know the provenance of the library. Many O/S projects use Apache
> commons libraries for example. Nobody compiles them, everybody just use
> them. I trust this library. I can get sources, but would you examine
> each line of the code to be sure that the library is O
On Fri, Jan 16, 2009 at 9:08 AM, James Carlson
wrote:
> Petr Slechta writes:
>> OK, if everything should be compiled (even if there are projects in SFW
>> that do not do it), should I compile the libraries as part of findbugs
>> project, or should I create separate project for each library (or se
On Fri, Jan 16, 2009 at 7:55 AM, Petr Slechta wrote:
>
> I strongly believe that nobody will fix jar libraries. If there is a
> problem and new library is available, we can get it and replace it. We
> don't need to compile it.
Trust, but verify
http://blogs.zdnet.com/security/?p=2016&tag=nl.
Brian Utterback writes:
> From a sustaining point of view, having multiple copies of things is
> a nightmare. Suppose a security issue comes up with one of the
> components? We then have to find and fix all those copies. If we do
> what you suggest and include pre-compiled components, then we c
Petr Slechta wrote:
>> /usr/share/lib/java/
> My personal opinion is that sharing all jar libraries is not good idea.
> If every application has its own copies of jars then it is independent.
> (Uninstallation of other application cannot brake it.) Jar files are
> small and today we have disk
I would like some clarification on jar file porting for
future arc cases.
findbugs plans to integrate the following project private
jar files.
163 f none usr/share/lib/java/findbugs/asm-analysis-3.1.jar
164 f none usr/share/lib/java/findbugs/asm-xml-3.1.jar
165 f none usr/share/lib/java/findbugs/
I have updated the deliverables list and the FOSS checklist with the
requested changes. As there are no further issues and the fast track
timer has expired, I have marked this case as "closed approved".
Petr Slechta wrote:
> Thanks to everyone who participated! I believe other java applications
Thanks to everyone who participated! I believe other java applications
will be able to go through the LSARC review faster... :-)
Marry Christmas and Happy New Year to everyone!
Petr
Tom Childers wrote:
> With those two minor changes, I have no issues. I think we can
> finally close this :-)
With those two minor changes, I have no issues. I think we can
finally close this :-) Thanks, Petr.
-tdc
On Dec 17, 2008, at 8:20 AM, Petr Slechta wrote:
> I believe we can remove the two items from the list of interfaces
> easily... Less interfaces, less sustaining... :-)
>
> Petr
>
> Dane
I believe we can remove the two items from the list of interfaces
easily... Less interfaces, less sustaining... :-)
Petr
Danek Duvall wrote:
> On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote:
>
>
>> I think that this is documenting the location, rather than the contents of
>>
Hello LSARC reviewers!
I need to close this LSARC case (we have agreement on package structure).
I suppose that foss checklist needs to be updated:
http://sac.eng.sun.com/Archives/CaseLog/arc/LSARC/2008/642/fosslist.txt
The new version of section 4.0 is below:
4.0 Interfaces
(see http://www.
I think that this is documenting the location, rather than the
contents of these directories.
Danek Duvall wrote:
> On Wed, Dec 17, 2008 at 12:09:33PM +0100, Petr Slechta wrote:
>
>>/usr/share/doc/findbugs uncommitted documentation and
>> license
>
> Documentation isn't an in
I have update the case directory with the changes to the foss
checklist. I have reset the timer to this Friday, since the only issue
was where to install the files and what to name them, which now is
resolved. I think til Friday should give everyone a chance to review
the changes. If any one di
On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote:
> I think that this is documenting the location, rather than the contents of
> these directories.
Projects document exported (and imported) interfaces. Exported interfaces
are exported because the project team expects them to be i
On Wed, Dec 17, 2008 at 12:09:33PM +0100, Petr Slechta wrote:
>/usr/share/doc/findbugs uncommitted documentation and license
Documentation isn't an interface, so this shouldn't be in the interface
table.
>/usr/share/lib/java/findbugs uncommitted findbugs' private
Please see the new version of package structure:
/usr/bin/findbugs
/usr/share/doc/findbugs
/usr/share/doc/findbugs/LICENSE.txt
/usr/share/doc/findbugs/README.txt
/usr/share/doc/findbugs/
/usr/share/doc/findbugs/manual/
/usr/share/findbugs
/usr/share/findbugs/bin
/usr/share/findbugs/bin/addMessages
Correcting the extra star characters in paths...
Petr
Petr Slechta wrote:
> Dear LSARC reviewers,
>
> please confirm, that the following structure of findbugs package is OK:
>
> /usr/bin/findbugs
> /usr/share/doc/findbugs
> /usr/share/doc/findbugs/LICENSE.txt
> /usr/share/doc/findbugs/README.txt
>
Dear LSARC reviewers,
please confirm, that the following structure of findbugs package is OK:
/usr/bin/*findbugs*
/usr/share/doc/*findbugs*
/usr/share/doc/*findbugs*/LICENSE.txt
/usr/share/doc/*findbugs*/README.txt
/usr/share/doc/*findbugs*/
/usr/share/doc/*findbugs*/manual/
/usr/share/*findbugs*
On Tue, Dec 16, 2008 at 07:53:13PM +0100, Petr Slechta wrote:
> [ ... ]
> /usr/share/lib/java/findbugs/dom4j-1.6.1.jar
> /usr/share/lib/java/findbugs/findbugs-1.3.4.jar
> /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar
> /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar
On Tue, Dec 16, 2008 at 07:36:53PM +0100, Petr Slechta wrote:
> please confirm, that the following structure of findbugs package is OK:
I assume that there aren't actually any asterisks in the pathnames ...
> /usr/share/lib/java/*findbugs*/lib/annotations-1.3.4.jar
> /usr/share/lib/java/*findbug
Jim Walker wrote:
> Tom Childers wrote:
>> Hello, Petr.
>>
>> Is that an acceptable solution? -tdc
>>
>> On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote:
>>
>>> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote:
>>>
Looking at this case, which has been sitting for a couple of
w
Tom Childers wrote:
> Hello, Petr.
>
> Is that an acceptable solution? -tdc
>
> On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote:
>
>> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote:
>>
>>> Looking at this case, which has been sitting for a couple of
>>> weeks, I realize that Petr
Hello, Petr.
Is that an acceptable solution?
-tdc
On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote:
> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote:
>
>> Looking at this case, which has been sitting for a couple of weeks, I
>> realize that Petr has raised an issue that we need to c
Hello all LSARC members!
Please let me know the final decision regarding the packaging structure
of findbugs (or more generally of any Java application under
OpenSolaris). This LSARC is running already for a long time and I need
to move forward with my task. I would be happy to update my LSARC
John Plocher wrote:
> On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers wrote:
>
>> ... then links may get changed and cause things to break.
>>
>
>
>> We asked the team to adopt the convention established for junit, LSARC/
>> 2008/633, similar to /usr/lib:
>>
>>/usr/share/lib/java/
On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers wrote:
>... then links may get changed and cause things to break.
> We asked the team to adopt the convention established for junit, LSARC/
> 2008/633, similar to /usr/lib:
>
>/usr/share/lib/java/junit.jar link to most recent version
>
On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote:
> Looking at this case, which has been sitting for a couple of weeks, I
> realize that Petr has raised an issue that we need to clarify. If we use
> links in /usr/share/java to point to the most recent version of each
> component, an
LSARC members,
Looking at this case, which has been sitting for a couple of weeks, I
realize that Petr has raised an issue that we need to clarify. If we
use links in /usr/share/java to point to the most recent version of
each component, and underlying components can be delivered by
differ
Hello all,
I want to be clear about installation structure of findbugs.
The original proposal was: (please pay special attention on
/usr/share/java/findbugs/* files)
---
/usr/bin/findbugs
/usr/share/applications/jpackage-findbugs.desktop
/usr/share/doc/findbugs
/usr/share/doc/findbugs/LICENSE.t
Hello, Petr and Brian.
We have a solution. Please place the jar file and link in /usr/share/
lib/java.
/usr/share/lib/java/findbugs.jar, which links to
/usr/share/lib/java/indbugs-1.3.6.jar
Can you please update the man page, FOSS checklist (section 4) and one-
pa
Hello Brian and everybody,
what is the current status of FindBugs ARC? Is there any
decision/recommendation how to handle Java apps on OpenSolaris?
Thanks!
Petr
Brian Utterback wrote:
> I was not involved in the prior Junit discussions. Can someone tell me
> what the planned method of dealing
I was not involved in the prior Junit discussions. Can someone tell me
what the planned method of dealing with layered Java packages is going
to be? Would it be acceptable to install into /usr/findbugs-1.3.6 with
a symbolic link from /usr/bin/findbugs to
/usr/findbugs-1.3.6/bin/findbugs?
As to
Right. I was on the call. I will work with Petr to resolve the missing
API issues, and we eagerly await the opinion as to how and where it
should be installed.
Tom Childers wrote:
> Brian,
>
> We discussed this case, and the junit case, in our OpenARC meeting this
> morning. We are extending
Brian,
We discussed this case, and the junit case, in our OpenARC meeting
this morning. We are extending the timer on this fast-track to Friday:
1. we will be writing an opinion for the junit case, 2008/633, and the
content will impact the location of your deliverables. We are talking
abou
Yes, it applies to all FOSS projects.
But it's very much a question of practical consequence for using FOSS.
What is "architectural" exactly?
AFAIK maintenance *is* an architectural question because it speaks
directly to:
- version or version(s) installed
- when and how versions are updated
-
> 0. Lots of our developers work on multiple platforms. For me at
> least, I prefer a setup that's as similar as possible on all
> machines. So Solaris packages are of little interest to me (but I
> don't work on Solaris).
But I would much rather that someone else took responsibilty for supplyi
On Mon, Oct 27, 2008 at 11:50:06AM -0700, Lloyd Chambers wrote:
> 1. When a new final FindBugs release appears, if it's not added to
> Solaris promptly, then who will want to use the Solaris version? The
> update latency must not be longer than a month.
This applies to all of the FOSS project
I disagree. The incremental advantage of using a slightly later
version than the one installed is unlikely to persuade developers to
download a later one. Looking the changelog for findbugs, the features
are evolutionary, not revolutionary from one rev to the next.
Lloyd Chambers wrote:
> Petr,
First, I'm not necessarily opposed to having this in Solaris.
0. Lots of our developers work on multiple platforms. For me at
least, I prefer a setup that's as similar as possible on all
machines. So Solaris packages are of little interest to me (but I
don't work on Solaris).
1. When a n
Petr,
From my viewpoint as a developer, I'm prepared to download the
current version, which I want preferentially because it will have the
latest goodies. I'm not all that interested in having a pre-installed
versions, because I can just as well keep my own version of choice
around. So
On Wed, Oct 22, 2008 at 09:03:15AM -0700, John Plocher wrote:
> Jyri Virkki wrote:
> > But, I find Java apps/libraries to be a special case. Most Linux
> > distros have historically not been very Java friendly. ...
> >
> > Sun has a certain fondness of Java though, so it makes sense to make
> > Op
Darren J Moffat wrote:
> in the architecture of Solaris. As others have asked how does this help
> Solaris ? I really think this belongs as part of NetBeans more than
> Solaris.
>
> I also really dislike the very generic /usr/bin/findbugs name given what
> this actually does.
How then coul
Petr Slechta wrote:
> Anyway, findbugs were approved by our director to be ported to Solaris.
> If you think it should not be ported, just let me know your objections
> and I may discuss it one more time...
Just because "some director" approved it doesn't mean it actually fits
in the architectu
Jyri Virkki wrote:
> But, I find Java apps/libraries to be a special case. Most Linux
> distros have historically not been very Java friendly. ...
>
> Sun has a certain fondness of Java though, so it makes sense to make
> OpenSolaris the best platform for Java development & deployment.
> Making us
Darren J Moffat wrote:
> Just because "some director" approved it doesn't mean it actually fits
> in the architecture of Solaris. As others have asked how does this help
> Solaris ? I really think this belongs as part of NetBeans more than
> Solaris.
>
I think we have already addressed th
> Darren J Moffat wrote:
>
> > in the architecture of Solaris. As others have
> asked how does this help
> > Solaris ? I really think this belongs as part of
> NetBeans more than
> > Solaris.
> >
> > I also really dislike the very generic
> /usr/bin/findbugs name given what
> > this actuall
Peter Tribble wrote:
> On Tue, Oct 21, 2008 at 6:57 PM, Tom Childers wrote:
>
>> Petr,
>>
>> I have several questions about this project. Since this is an open
>> case, I'm changing the cc: to lsarc-ext at sun.com.
>>
>> I am wondering what requirement we are trying to fill with this
>> projec
Tom Childers wrote:
> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote:
>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, Tom Childers wrote:
>>> Petr,
>>>
>>> I have several questions about this project. Since this is an open
>>> case, I'm changing the cc: to lsarc-ext at sun.com.
>>>
>>> I am wonder
Hello Tom,
Tom Childers wrote:
> Petr,
>
> I have several questions about this project. Since this is an open
> case, I'm changing the cc: to lsarc-ext at sun.com.
>
> I am wondering what requirement we are trying to fill with this
> project. FindBugs is downloadable, gets updated frequently, a
Tom Childers wrote:
>
> I am wondering what requirement we are trying to fill with this
> project. FindBugs is downloadable, gets updated frequently, and is not
This doesn't seem relevant to the case IMO. Every 3rd party open
source component is by definition downloadable and people can just g
On Tue, Oct 21, 2008 at 6:57 PM, Tom Childers wrote:
> Petr,
>
> I have several questions about this project. Since this is an open
> case, I'm changing the cc: to lsarc-ext at sun.com.
>
> I am wondering what requirement we are trying to fill with this
> project. FindBugs is downloadable, gets u
Dean Roehrich writes:
> You're asking if they're going to port every point release, or if, once per
> time-unit (week, quarter, year, whatever) they'll just pick the latest at that
> time? Doesn't this apply to every FOSS case? Where does this question
> belong--ARC, C-Team, Management? It's not
On Tue, Oct 21, 2008 at 12:24:05PM -0700, Tom Childers wrote:
> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote:
> >On Tue, Oct 21, 2008 at 10:57:54AM -0700, Tom Childers wrote:
> >>Petr,
> >>
> >>I have several questions about this project. Since this is an open
> >>case, I'm changing the cc: t
On Tue, Oct 21, 2008 at 10:57:54AM -0700, Tom Childers wrote:
> Petr,
>
> I have several questions about this project. Since this is an open
> case, I'm changing the cc: to lsarc-ext at sun.com.
>
> I am wondering what requirement we are trying to fill with this
> project. FindBugs is downlo
On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote:
> On Tue, Oct 21, 2008 at 10:57:54AM -0700, Tom Childers wrote:
>> Petr,
>>
>> I have several questions about this project. Since this is an open
>> case, I'm changing the cc: to lsarc-ext at sun.com.
>>
>> I am wondering what requirement we are t
Petr,
I have several questions about this project. Since this is an open
case, I'm changing the cc: to lsarc-ext at sun.com.
I am wondering what requirement we are trying to fill with this
project. FindBugs is downloadable, gets updated frequently, and is not
prepackaged on any other platf
60 matches
Mail list logo
