You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2014/02/10 20:50:17 UTC
[Vote] (RIVER-432) Jar files in svn and src distributions
As discussion has settled somewhat, I would like to call another vote to accept the latest patch described in
https://issues.apache.org/jira/browse/RIVER-432
The patch removes the archived jar files for Velocity and ASM and replaces them with Apache Ivy scripts that download the jars from Maven Central the first time a build is done. From then on, the jar files are in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
Voting will remain open at least until 2000 UTC Feb 13, 2014.
Cheers,
Greg.
On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>
>> In order to gain some time to discuss this first i will vote -1.
>>
>> First, we decided to NOT remove velocity builder.
>
> When I read the email chain, my impression was that we wanted to remove it (to quote you Sim, “To be honest, I hate it”), but there was a dependency on it in the ‘extras’ folder that was added in the trunk branch. As there is no ‘extras’ in the 2.2 branch, and that is what this patch applies to, I thought it was fair to remove VelocityConfigurationBuilder from the 2.2 branch. Perhaps we should revisit the ConfigurationBuilder approach in another thread. For now I’ll spin another patch that doesn’t remove VelocityConfigurationBuilder.
>
>>
>> Second, no need to remove the jars as specified in your own comments on RIVER-432.
>>
>> Pulling in external jars at compile time, shall we start here?
>>
>> They are already in the svn. They are already in the build scripts. What does this patch fix? No legal problems?
>>
>
> Apache policy is somewhat unclear on this point. One needs to examine the mailing lists for clues on what we should really do. I will argue that:
>
> 1 - The fundamental distribution model of Apache is source code, not binaries.
> 2 - Distributing binaries is tolerated but not encouraged. Since the svn repository can be seen as a distribution point, binaries in svn are also tolerated but not encouraged.
> 3 - Downloading dependency binaries at build time is technologically easy, provides the same guarantees as putting them in cvs, and avoids the question of effectively distributing someone else’s code.
>
> All these together suggest that although we’re technically OK to put dependency jars in a “-deps” package (note that the status quo _is_ unacceptable - at the very least, we need to restructure the dependencies into a “-deps” binary package), there is some policy uncertainty which we avoid totally by having dependencies downloaded from a known-good source at build time.
>
> Let’s examine these points:
>
> 1 - The fundamental distribution model of Apache is source code, not binaries. Apache began with httpd. Back in those days, “Open Source” software was distributed in source form only, simply because it was mostly intended for Unix systems (then later Linux). I recall the first release of Perl coming down as a ten-part uunet news message. Part of this distribution model was practical necessity - System differences made it necessary to compile your software on the hardware it was going to run on. Part of it was open-source philosophy. Having the source code meant that you could take a look at it and verify that it wasn’t hazardous to your operations.
>
> In any case, the way we use to use open source software was (“./configure; make; make install”). If the software had dependencies, you built them from source, for the same reasons.
>
> Now, as time has gone on, we’ve gotten used to having the JVM as a common runtime, and jar files as a common binary distribution medium. But the Apache Foundation’s mandate is to produce open source software that is freely usable under the Apache License. That means source code is at the heart of Apache, despite the rest of the world’s comfort with binaries. Hence Roy’s statements in (1):
>
>> Class files are not open source. Jar files filled with class files
>> are not open source. The fact that they are derived from open source
>> is applicable only to what we allow projects to be dependent upon,
>> not what we vote on as a release package. Release votes are on verified
>> open source artifacts. Binary packages are separate from source packages.
>> One cannot vote to approve a release containing a mix of source and
>> binary code because the binary is not open source and cannot be verified
>> to be safe for release (even if it was derived from open source).
>>
>> I thought that was frigging obvious. Why do I need to write documentation
>> to explain something that is fundamental to the open source definition?
> He’s talking about binary packages, not jar files in svn, but I read that (and many other emails) as a distaste for binary distributions.
>
> In fact, if you look at Apache httpd’s download page, it doesn’t appear that the Apache project publishes any Unix or Linux binaries. They leave that to other organizations.
>
> 2 - Distributing binaries is tolerated but not encouraged. Since the svn repository can be seen as a distribution point, binaries in svn are also tolerated but not encouraged.
>
> It’s hard to find a single reference that encapsulates this outlook, but that’s the impression I get from reading the various mailing lists. For instance, Sam Ruby says (2):
>> IMO, our projects release source. So, our projects should not maintain object/binary artifacts
>> in their svn release tree, regardless of license (category a or b).
> There is some debate on whether the svn tree should be considered a distribution point. Incubator releases are regularly called out for not having “NOTICE” and “RELEASE” files at all reasonable checkout points in svn. [LEGAL-26] (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and remains unresolved.
>
> Doug Cutting (3) says:
>> On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> * Source control is not an Apache distribution and hence we do not need to
>>> have LICENSE and NOTICE files in source control, it can be a nice
>>> convenience, but there is no *requirement*.
>>
>> I think perhaps you're looking for clear lines where things are
>> actually a bit fuzzy. Certainly releases are official distributions
>> and need LICENSE and NOTICE files. That line is clear. On the other
>> hand, we try to discourage folks from thinking that source control is
>> a distribution. Rather we wish it to be considered our shared
>> workspace, containing works in progress, not yet always ready for
>> distribution to folks outside the foundation. But, since we work in
>> public, folks from outside the foundation can see our shared workspace
>> and might occasionally mistake it for an official distribution. We'd
>> like them to still see a LICENSE and NOTICE file. So it's not a
>> hard-and-fast requirement that every tree that can possibly be checked
>> out have a LICENSE and NOTICE file at its root, but it's a good
>> practice for those trees that are likely to be checked out have them,
>> so that folks who might consume them are well informed.
> Again, he’s not talking directly about jar files in svn, however I think his statement that “since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution” applies here. Fundamentally, the decision on how and where to distribute ‘velocity.jar’ rightly belongs with the Velocity group and I don’t think we ought to redistribute it.
>
> 3 - Downloading dependency binaries at build time is technologically easy, provides the same guarantees as putting them in cvs, and avoids the question of effectively distributing someone else’s code.
>
> There doesn’t seem to be clear policy in the ASF on this, as evidenced by the frequent debates on it, and the lack of documentation. I’ve tried to lay out an argument that having jars in svn is not encouraged by the ASF (really, it’s not in line with the ASF’s charter), even if it isn’t disallowed. You may disagree, and I won’t claim I’ve made a strong argument, simply because the policy isn’t clear. So instead of going through arguments that amount to differences of opinion on Apache policy, let’s use a technological solution that is simple, common, and avoids the question altogether, by automatically downloading the dependencies at build time.
>
> Projects that use Maven do this automatic download as standard practice (that’s what Maven does, and that’s what the Maven Central infrastructure is there to support). We don’t use Maven, which is fine (our customers have asked us to make our binaries available in Maven Central, and we’ve done that). Apache Ivy is a popular add-on to Apache Ant that provides similar dependency resolution to an Ant-based build.
>
> I was a little surprised how easy it was to persuade Ivy to get the required dependencies at build time. The “ivy.xml” file is 39 lines including the ASL header (which by the way I forgot to include in the patch - I’ll fix that). There are about 50 lines added to ‘build.xml’ to download Ivy and then download the required jar files
>
> So, given that the status-quo seems to be unacceptable (Roy talks about not having jar files in the open-source trees, only in “-deps” and “tools” trees), we have two options:
>
> (a) - restructure the svn repository and the build to allow a separate “-deps” distribution. This wouldn’t affect our binary distributions (note that I’m no longer using the term “binary release”), but to build from source, a user would have to download a separate archive, unpack it, and then copy those files into the directory that was unpacked from the source release. This option effectively still has us distributing dependent binaries, which is not the goal of the ASF, just with a disclaimer that says “this isn’t an ASF release, its just a binary distribution put together by a committer for your convenience, so don’t feel you should trust it too much”.
>
> (b) - use Ivy to get the jars from Maven Central automatically as part of the build.
>
> I think (b) is the option that causes the least hassle for our downstream consumers, and not much hassle for us.
>
>
>> Pulling external jars at compile time also makes it more difficult to certify the software. In order to certify the software you need to establish baseline that will be garanteed the same, even if you pull it from the archive 10 years later.
>
> As I said above, Apache’s focus is creating software that can be built from source, not distributing binaries (note that QCG or another company might have a different focus, and is perfectly able to distribute binaries under the Apache license). I think a reasonably prudent user would ask “How can I trust the ‘velocity.jar’ that’s included in this binary?” And the answer would be either “because I built it from source and installed it in my corporate repository” (very cautious, but not unheard-of) or “It was published by the Velocity group to a trusted repository, Maven Central” (more common).
>
> If you look in the “ivy.xml” file you’ll see that the dependencies are specified using Maven-style “group-artifact-version” coordinates. Old versions are maintained in Maven Central forever. I suppose it’s possible that a publisher could convince Maven Central to remove a version for some reason (security or licensing problems perhaps), but then, would we want to be distributing that version in a “-deps” package?
>
> I agree that it’s not enough to just say “you need to download such-and-such jar”, hence the automatic download managed by “Ivy” from Maven Central.
>
>> It is not a high level project that builds on several frameworks. It is a lowlevel system library. The stuff below the stack is minimal. The number of jars we use is limited. Why bother?
>>
>
> In the currently released branches, the dependencies are limited to ASM and Velocity. Looking forward to the trunk branch and the qa_refactor branch, the number of external dependencies seem to be increasing (IMO I don’t like that, because I also view River as a low level system library, but I’m only one PMC member). We need to get in front of the problem before we start distributing large numbers of dependencies.
>
> This point rolls in with the general question of jar files in version control. I was always taught that version control was for source code, and putting binaries into version control was a bad idea. In addition, there are practical problems - with older systems like cvs, even doing an update or commit effectively downloads the binaries, which slows things down if there are large binary files. On newer distributed version control systems like git or Mercurial, the entire repository, including all versions of binary artifacts, comes down with the project checkout. Currently, we have one version of relatively few jar files in our repository, so it’s not a major issue. But it gets worse as time goes on. So I suggest we work out the technology now to avoid the problem.
>
>> Gr. Simon
>>
>
> Thanks for the questions, Sim. I hope you’ll come around to removing your ‘-1’.
>
> Cheers,
>
> Greg
>
> Footnotes
> ——————
>
> (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
> (2) - Sam Ruby - http://s.apache.org/r5
> (3) - Doug Cutting - http://s.apache.org/GNP
>
>> On 02-01-14 18:22, Greg Trasuk wrote:
>>>
>>> Hello all:
>>>
>>> Please have a look at the patch mentioned below and cast a vote on it.
>>>
>>> The main idea is to remove the dependency jar files from the source distribution. As a side effect of using Ivy, it becomes reasonable to remove them from the svn archive as well. Also, the Velocity dependency was there to support the VelocityConfigurationBuilder. We had discussed removing that component, so rather than move that dependency to Ivy, I’ve removed VelocityConfigurationBuilder.
>>>
>>> It’s arguable whether the VelocityConfigurationBuider was part of the official Jini API (I see it as a utility, not API), so I don’t think this commit actually requires a vote. However, it does seem like a significant change to the build process that ought to be reviewed. So I propose to treat this as a “lazy consensus” vote, and will commit the change to the 2.2 branch if there are no objections in 72 hours (i.e. 1730UTC 20140105).
>>>
>>> At the same time, based on discussions over on general@incubator.apache.org, I’ll withdraw my assertion that we can’t have jars in svn. Those interested may want to check out the thread at http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>> On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA) <ji...@apache.org> wrote:
>>>
>>>>
>>>> [ https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>>>
>>>> Greg Trasuk updated RIVER-432:
>>>> ------------------------------
>>>>
>>>> Attachment: river-2_2_remove_jars.diff
>>>>
>>>> The attached patch for the 2.2 branch does the following:
>>>> - removes the 'asm' directory and 'tests/lib' directories which currently contain the asm library, mockito, and junit jars.
>>>> - Modifies 'build.xml', 'common.xml', and adds 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at build time, and then used to retrieve the libraries mentioned above from Maven Central. This removes the need to have the jar files in svn.
>>>> - Removes (as per discussion http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E) the VelocityConfigBuilder, and associated Velocity jars. Note that the 'extras' folder is not present in the 2.2 branch, so Sim's last comments in the thread do not apply.
>>>>
>>>>> Jar files in svn and src distributions
>>>>> --------------------------------------
>>>>>
>>>>> Key: RIVER-432
>>>>> URL: https://issues.apache.org/jira/browse/RIVER-432
>>>>> Project: River
>>>>> Issue Type: Bug
>>>>> Reporter: Greg Trasuk
>>>>> Attachments: river-2_2_remove_jars.diff
>>>>>
>>>>>
>>>>> Recent traffic on the incubator lists has pointed out that including jar files for dependencies in the subversion repository and the source distributions is against Apache policy.
>>>>> In River, the following libraries appear in the Subversion repository and the source distributions (these are from trunk, a smaller set appear in the 2.2 branch):
>>>>> animal-sniffer
>>>>> asm
>>>>> bouncy-castle
>>>>> dnsjava
>>>>> high-scale-lib
>>>>> rc-libs
>>>>> velocity
>>>>> They all have to go. What are we using them for? As I understand it, we were going to remove the VelocityConfigurationBuilder, so that's not a problem. Some of the others are available from Maven Central, so we can get them at build time using Ivy or another build tool. Which ones are actually required? And where did they come from?
>>>>
>>>>
>>>>
>>>> --
>>>> This message was sent by Atlassian JIRA
>>>> (v6.1.5#6160)
>>>
>>
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
+1
Greg Trasuk
On Feb 10, 2014, at 2:50 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> As discussion has settled somewhat, I would like to call another vote to accept the latest patch described in
> https://issues.apache.org/jira/browse/RIVER-432
>
> The patch removes the archived jar files for Velocity and ASM and replaces them with Apache Ivy scripts that download the jars from Maven Central the first time a build is done. From then on, the jar files are in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
>
> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>
> Cheers,
>
> Greg.
>
>
> On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>>
>> On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>>
>>> In order to gain some time to discuss this first i will vote -1.
>>>
>>> First, we decided to NOT remove velocity builder.
>>
>> When I read the email chain, my impression was that we wanted to remove it (to quote you Sim, “To be honest, I hate it”), but there was a dependency on it in the ‘extras’ folder that was added in the trunk branch. As there is no ‘extras’ in the 2.2 branch, and that is what this patch applies to, I thought it was fair to remove VelocityConfigurationBuilder from the 2.2 branch. Perhaps we should revisit the ConfigurationBuilder approach in another thread. For now I’ll spin another patch that doesn’t remove VelocityConfigurationBuilder.
>>
>>>
>>> Second, no need to remove the jars as specified in your own comments on RIVER-432.
>>>
>>> Pulling in external jars at compile time, shall we start here?
>>>
>>> They are already in the svn. They are already in the build scripts. What does this patch fix? No legal problems?
>>>
>>
>> Apache policy is somewhat unclear on this point. One needs to examine the mailing lists for clues on what we should really do. I will argue that:
>>
>> 1 - The fundamental distribution model of Apache is source code, not binaries.
>> 2 - Distributing binaries is tolerated but not encouraged. Since the svn repository can be seen as a distribution point, binaries in svn are also tolerated but not encouraged.
>> 3 - Downloading dependency binaries at build time is technologically easy, provides the same guarantees as putting them in cvs, and avoids the question of effectively distributing someone else’s code.
>>
>> All these together suggest that although we’re technically OK to put dependency jars in a “-deps” package (note that the status quo _is_ unacceptable - at the very least, we need to restructure the dependencies into a “-deps” binary package), there is some policy uncertainty which we avoid totally by having dependencies downloaded from a known-good source at build time.
>>
>> Let’s examine these points:
>>
>> 1 - The fundamental distribution model of Apache is source code, not binaries. Apache began with httpd. Back in those days, “Open Source” software was distributed in source form only, simply because it was mostly intended for Unix systems (then later Linux). I recall the first release of Perl coming down as a ten-part uunet news message. Part of this distribution model was practical necessity - System differences made it necessary to compile your software on the hardware it was going to run on. Part of it was open-source philosophy. Having the source code meant that you could take a look at it and verify that it wasn’t hazardous to your operations.
>>
>> In any case, the way we use to use open source software was (“./configure; make; make install”). If the software had dependencies, you built them from source, for the same reasons.
>>
>> Now, as time has gone on, we’ve gotten used to having the JVM as a common runtime, and jar files as a common binary distribution medium. But the Apache Foundation’s mandate is to produce open source software that is freely usable under the Apache License. That means source code is at the heart of Apache, despite the rest of the world’s comfort with binaries. Hence Roy’s statements in (1):
>>
>>> Class files are not open source. Jar files filled with class files
>>> are not open source. The fact that they are derived from open source
>>> is applicable only to what we allow projects to be dependent upon,
>>> not what we vote on as a release package. Release votes are on verified
>>> open source artifacts. Binary packages are separate from source packages.
>>> One cannot vote to approve a release containing a mix of source and
>>> binary code because the binary is not open source and cannot be verified
>>> to be safe for release (even if it was derived from open source).
>>>
>>> I thought that was frigging obvious. Why do I need to write documentation
>>> to explain something that is fundamental to the open source definition?
>> He’s talking about binary packages, not jar files in svn, but I read that (and many other emails) as a distaste for binary distributions.
>>
>> In fact, if you look at Apache httpd’s download page, it doesn’t appear that the Apache project publishes any Unix or Linux binaries. They leave that to other organizations.
>>
>> 2 - Distributing binaries is tolerated but not encouraged. Since the svn repository can be seen as a distribution point, binaries in svn are also tolerated but not encouraged.
>>
>> It’s hard to find a single reference that encapsulates this outlook, but that’s the impression I get from reading the various mailing lists. For instance, Sam Ruby says (2):
>>> IMO, our projects release source. So, our projects should not maintain object/binary artifacts
>>> in their svn release tree, regardless of license (category a or b).
>> There is some debate on whether the svn tree should be considered a distribution point. Incubator releases are regularly called out for not having “NOTICE” and “RELEASE” files at all reasonable checkout points in svn. [LEGAL-26] (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and remains unresolved.
>>
>> Doug Cutting (3) says:
>>> On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>> * Source control is not an Apache distribution and hence we do not need to
>>>> have LICENSE and NOTICE files in source control, it can be a nice
>>>> convenience, but there is no *requirement*.
>>>
>>> I think perhaps you're looking for clear lines where things are
>>> actually a bit fuzzy. Certainly releases are official distributions
>>> and need LICENSE and NOTICE files. That line is clear. On the other
>>> hand, we try to discourage folks from thinking that source control is
>>> a distribution. Rather we wish it to be considered our shared
>>> workspace, containing works in progress, not yet always ready for
>>> distribution to folks outside the foundation. But, since we work in
>>> public, folks from outside the foundation can see our shared workspace
>>> and might occasionally mistake it for an official distribution. We'd
>>> like them to still see a LICENSE and NOTICE file. So it's not a
>>> hard-and-fast requirement that every tree that can possibly be checked
>>> out have a LICENSE and NOTICE file at its root, but it's a good
>>> practice for those trees that are likely to be checked out have them,
>>> so that folks who might consume them are well informed.
>> Again, he’s not talking directly about jar files in svn, however I think his statement that “since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution” applies here. Fundamentally, the decision on how and where to distribute ‘velocity.jar’ rightly belongs with the Velocity group and I don’t think we ought to redistribute it.
>>
>> 3 - Downloading dependency binaries at build time is technologically easy, provides the same guarantees as putting them in cvs, and avoids the question of effectively distributing someone else’s code.
>>
>> There doesn’t seem to be clear policy in the ASF on this, as evidenced by the frequent debates on it, and the lack of documentation. I’ve tried to lay out an argument that having jars in svn is not encouraged by the ASF (really, it’s not in line with the ASF’s charter), even if it isn’t disallowed. You may disagree, and I won’t claim I’ve made a strong argument, simply because the policy isn’t clear. So instead of going through arguments that amount to differences of opinion on Apache policy, let’s use a technological solution that is simple, common, and avoids the question altogether, by automatically downloading the dependencies at build time.
>>
>> Projects that use Maven do this automatic download as standard practice (that’s what Maven does, and that’s what the Maven Central infrastructure is there to support). We don’t use Maven, which is fine (our customers have asked us to make our binaries available in Maven Central, and we’ve done that). Apache Ivy is a popular add-on to Apache Ant that provides similar dependency resolution to an Ant-based build.
>>
>> I was a little surprised how easy it was to persuade Ivy to get the required dependencies at build time. The “ivy.xml” file is 39 lines including the ASL header (which by the way I forgot to include in the patch - I’ll fix that). There are about 50 lines added to ‘build.xml’ to download Ivy and then download the required jar files
>>
>> So, given that the status-quo seems to be unacceptable (Roy talks about not having jar files in the open-source trees, only in “-deps” and “tools” trees), we have two options:
>>
>> (a) - restructure the svn repository and the build to allow a separate “-deps” distribution. This wouldn’t affect our binary distributions (note that I’m no longer using the term “binary release”), but to build from source, a user would have to download a separate archive, unpack it, and then copy those files into the directory that was unpacked from the source release. This option effectively still has us distributing dependent binaries, which is not the goal of the ASF, just with a disclaimer that says “this isn’t an ASF release, its just a binary distribution put together by a committer for your convenience, so don’t feel you should trust it too much”.
>>
>> (b) - use Ivy to get the jars from Maven Central automatically as part of the build.
>>
>> I think (b) is the option that causes the least hassle for our downstream consumers, and not much hassle for us.
>>
>>
>>> Pulling external jars at compile time also makes it more difficult to certify the software. In order to certify the software you need to establish baseline that will be garanteed the same, even if you pull it from the archive 10 years later.
>>
>> As I said above, Apache’s focus is creating software that can be built from source, not distributing binaries (note that QCG or another company might have a different focus, and is perfectly able to distribute binaries under the Apache license). I think a reasonably prudent user would ask “How can I trust the ‘velocity.jar’ that’s included in this binary?” And the answer would be either “because I built it from source and installed it in my corporate repository” (very cautious, but not unheard-of) or “It was published by the Velocity group to a trusted repository, Maven Central” (more common).
>>
>> If you look in the “ivy.xml” file you’ll see that the dependencies are specified using Maven-style “group-artifact-version” coordinates. Old versions are maintained in Maven Central forever. I suppose it’s possible that a publisher could convince Maven Central to remove a version for some reason (security or licensing problems perhaps), but then, would we want to be distributing that version in a “-deps” package?
>>
>> I agree that it’s not enough to just say “you need to download such-and-such jar”, hence the automatic download managed by “Ivy” from Maven Central.
>>
>>> It is not a high level project that builds on several frameworks. It is a lowlevel system library. The stuff below the stack is minimal. The number of jars we use is limited. Why bother?
>>>
>>
>> In the currently released branches, the dependencies are limited to ASM and Velocity. Looking forward to the trunk branch and the qa_refactor branch, the number of external dependencies seem to be increasing (IMO I don’t like that, because I also view River as a low level system library, but I’m only one PMC member). We need to get in front of the problem before we start distributing large numbers of dependencies.
>>
>> This point rolls in with the general question of jar files in version control. I was always taught that version control was for source code, and putting binaries into version control was a bad idea. In addition, there are practical problems - with older systems like cvs, even doing an update or commit effectively downloads the binaries, which slows things down if there are large binary files. On newer distributed version control systems like git or Mercurial, the entire repository, including all versions of binary artifacts, comes down with the project checkout. Currently, we have one version of relatively few jar files in our repository, so it’s not a major issue. But it gets worse as time goes on. So I suggest we work out the technology now to avoid the problem.
>>
>>> Gr. Simon
>>>
>>
>> Thanks for the questions, Sim. I hope you’ll come around to removing your ‘-1’.
>>
>> Cheers,
>>
>> Greg
>>
>> Footnotes
>> ——————
>>
>> (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
>> (2) - Sam Ruby - http://s.apache.org/r5
>> (3) - Doug Cutting - http://s.apache.org/GNP
>>
>>> On 02-01-14 18:22, Greg Trasuk wrote:
>>>>
>>>> Hello all:
>>>>
>>>> Please have a look at the patch mentioned below and cast a vote on it.
>>>>
>>>> The main idea is to remove the dependency jar files from the source distribution. As a side effect of using Ivy, it becomes reasonable to remove them from the svn archive as well. Also, the Velocity dependency was there to support the VelocityConfigurationBuilder. We had discussed removing that component, so rather than move that dependency to Ivy, I’ve removed VelocityConfigurationBuilder.
>>>>
>>>> It’s arguable whether the VelocityConfigurationBuider was part of the official Jini API (I see it as a utility, not API), so I don’t think this commit actually requires a vote. However, it does seem like a significant change to the build process that ought to be reviewed. So I propose to treat this as a “lazy consensus” vote, and will commit the change to the 2.2 branch if there are no objections in 72 hours (i.e. 1730UTC 20140105).
>>>>
>>>> At the same time, based on discussions over on general@incubator.apache.org, I’ll withdraw my assertion that we can’t have jars in svn. Those interested may want to check out the thread at http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
>>>>
>>>> Cheers,
>>>>
>>>> Greg.
>>>>
>>>> On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA) <ji...@apache.org> wrote:
>>>>
>>>>>
>>>>> [ https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>>>>
>>>>> Greg Trasuk updated RIVER-432:
>>>>> ------------------------------
>>>>>
>>>>> Attachment: river-2_2_remove_jars.diff
>>>>>
>>>>> The attached patch for the 2.2 branch does the following:
>>>>> - removes the 'asm' directory and 'tests/lib' directories which currently contain the asm library, mockito, and junit jars.
>>>>> - Modifies 'build.xml', 'common.xml', and adds 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at build time, and then used to retrieve the libraries mentioned above from Maven Central. This removes the need to have the jar files in svn.
>>>>> - Removes (as per discussion http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E) the VelocityConfigBuilder, and associated Velocity jars. Note that the 'extras' folder is not present in the 2.2 branch, so Sim's last comments in the thread do not apply.
>>>>>
>>>>>> Jar files in svn and src distributions
>>>>>> --------------------------------------
>>>>>>
>>>>>> Key: RIVER-432
>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-432
>>>>>> Project: River
>>>>>> Issue Type: Bug
>>>>>> Reporter: Greg Trasuk
>>>>>> Attachments: river-2_2_remove_jars.diff
>>>>>>
>>>>>>
>>>>>> Recent traffic on the incubator lists has pointed out that including jar files for dependencies in the subversion repository and the source distributions is against Apache policy.
>>>>>> In River, the following libraries appear in the Subversion repository and the source distributions (these are from trunk, a smaller set appear in the 2.2 branch):
>>>>>> animal-sniffer
>>>>>> asm
>>>>>> bouncy-castle
>>>>>> dnsjava
>>>>>> high-scale-lib
>>>>>> rc-libs
>>>>>> velocity
>>>>>> They all have to go. What are we using them for? As I understand it, we were going to remove the VelocityConfigurationBuilder, so that's not a problem. Some of the others are available from Maven Central, so we can get them at build time using Ivy or another build tool. Which ones are actually required? And where did they come from?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> This message was sent by Atlassian JIRA
>>>>> (v6.1.5#6160)
>>>>
>>>
>>>
>>> --
>>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
>
[Result][Vote] (RIVER-432) Jar files in svn and src distributions - Rejected
Posted by Greg Trasuk <tr...@stratuscom.com>.
Simon’s ‘-1’ represents a veto.
+1 Peter
+1 Greg
-1 Simon
I will close the JIRA issue.
Cheers,
Greg Trasuk.
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Peter Firmstone <ji...@zeus.net.au>.
+1 Peter.
On 13/02/2014 2:09 AM, Simon IJskes - QCG wrote:
> On 12-02-14 17:00, Greg Trasuk wrote:
>>
>> OK, fair enough. I’ll close this issue and open another one that
>> just makes sure the jars aren’t in the source distribution (that _is_
>> an Apache requirement) without adding Ivy.
>
> +1
>
>> In general, though, as we move to the build structure discussion, are
>> you OK with using dependency management. I’m not big on putting
>> other people’s software distributions into our source repository,
>> especially if we’re going to see more dependencies as time goes on.
>
> Yes, i'm ok. Clearly we are not gaining critical mass where it comes
> to gaining interest and new blood for much needed innovations and
> improvements. Whe cannot let Peter do the work on his own, and the
> longer we let Peter work in isolation, without bringing his work into
> the main trunk, the worse we are of.
>
> So if we need to change things, i see the adoptition of popular tools
> as a way to enlist others to work on river. Gradle i view as a bit
> much, maven should be general knowledge nowadays. I still claim we can
> do without it, but if we need a popular (and therefore recocnizable
> feel) to increase the adoption, i'm all for it. The way it is going
> right now, is an agony to most i think.
>
> Gr. Simon
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 12-02-14 17:00, Greg Trasuk wrote:
>
> OK, fair enough. I’ll close this issue and open another one that
> just makes sure the jars aren’t in the source distribution (that _is_
> an Apache requirement) without adding Ivy.
+1
> In general, though, as we move to the build structure discussion, are
> you OK with using dependency management. I’m not big on putting
> other people’s software distributions into our source repository,
> especially if we’re going to see more dependencies as time goes on.
Yes, i'm ok. Clearly we are not gaining critical mass where it comes to
gaining interest and new blood for much needed innovations and
improvements. Whe cannot let Peter do the work on his own, and the
longer we let Peter work in isolation, without bringing his work into
the main trunk, the worse we are of.
So if we need to change things, i see the adoptition of popular tools as
a way to enlist others to work on river. Gradle i view as a bit much,
maven should be general knowledge nowadays. I still claim we can do
without it, but if we need a popular (and therefore recocnizable feel)
to increase the adoption, i'm all for it. The way it is going right now,
is an agony to most i think.
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
Actually, for the sake of procedure, the vote will remain open until 20000UTC Feb 13, as per the original call. As it stands now, however, Sim’s -1 represents a veto.
Greg.
On Feb 12, 2014, at 11:00 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> OK, fair enough. I’ll close this issue and open another one that just makes sure the jars aren’t in the source distribution (that _is_ an Apache requirement) without adding Ivy.
>
> In general, though, as we move to the build structure discussion, are you OK with using dependency management. I’m not big on putting other people’s software distributions into our source repository, especially if we’re going to see more dependencies as time goes on.
>
> Cheers,
>
> Greg.
>
> On Feb 12, 2014, at 10:38 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>
>> On 12-02-14 15:56, Greg Trasuk wrote:
>>>
>>> Hi Sim,
>>>
>>> -1 votes need to have an explanation, for the archives.
>>
>> If it is so important to revise the build system, to me it is not, but you care a lot about it, we should view the problem on a wider scope. Why not put the effort in, to revise our whole build system?
>> I think it is important not just change things for no reason, as this is how i view the migration to ivy. I know ivy, i use ivy, but i cannot see this as a improvement to river.
>>
>> Let me know if this is unclear to you, or that you do not agree with me. The one is solvable the other isnt.
>>
>> Gr. Simon
>>
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
OK, fair enough. I’ll close this issue and open another one that just makes sure the jars aren’t in the source distribution (that _is_ an Apache requirement) without adding Ivy.
In general, though, as we move to the build structure discussion, are you OK with using dependency management. I’m not big on putting other people’s software distributions into our source repository, especially if we’re going to see more dependencies as time goes on.
Cheers,
Greg.
On Feb 12, 2014, at 10:38 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 12-02-14 15:56, Greg Trasuk wrote:
>>
>> Hi Sim,
>>
>> -1 votes need to have an explanation, for the archives.
>
> If it is so important to revise the build system, to me it is not, but you care a lot about it, we should view the problem on a wider scope. Why not put the effort in, to revise our whole build system?
> I think it is important not just change things for no reason, as this is how i view the migration to ivy. I know ivy, i use ivy, but i cannot see this as a improvement to river.
>
> Let me know if this is unclear to you, or that you do not agree with me. The one is solvable the other isnt.
>
> Gr. Simon
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 12-02-14 15:56, Greg Trasuk wrote:
>
> Hi Sim,
>
> -1 votes need to have an explanation, for the archives.
If it is so important to revise the build system, to me it is not, but
you care a lot about it, we should view the problem on a wider scope.
Why not put the effort in, to revise our whole build system?
I think it is important not just change things for no reason, as this is
how i view the migration to ivy. I know ivy, i use ivy, but i cannot see
this as a improvement to river.
Let me know if this is unclear to you, or that you do not agree with me.
The one is solvable the other isnt.
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Sim,
-1 votes need to have an explanation, for the archives.
I wonder if you could state again why you feel strongly enough about this issue to veto a small change to the build? How is it so important to have jar files in our svn repository rather than a widely recognized and stable global repository?
Cheers,
Greg.
On Feb 12, 2014, at 5:29 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 10-02-14 20:50, Greg Trasuk wrote:
>>
>> As discussion has settled somewhat, I would like to call another vote to accept the latest patch described in
>> https://issues.apache.org/jira/browse/RIVER-432
>>
>> The patch removes the archived jar files for Velocity and ASM and replaces them with Apache Ivy scripts that download the jars from Maven Central the first time a build is done. From then on, the jar files are in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
>>
>> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>>
>> Cheers,
>>
>> Greg.
>
>
> -1 .
>
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-02-14 20:50, Greg Trasuk wrote:
>
> As discussion has settled somewhat, I would like to call another vote to accept the latest patch described in
> https://issues.apache.org/jira/browse/RIVER-432
>
> The patch removes the archived jar files for Velocity and ASM and replaces them with Apache Ivy scripts that download the jars from Maven Central the first time a build is done. From then on, the jar files are in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
>
> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>
> Cheers,
>
> Greg.
-1 .
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Build system and Java 8 was: Re: [Vote] (RIVER-432) Jar files
in svn and src distributions
Posted by Peter Firmstone <ji...@zeus.net.au>.
No, I fixed the build system last time to support Java 5 language
features, I don't have the time or inclination to fix it again.
ClassDep needs to be able to find dependencies by analysing byte code.
So to support finding dependencies for Java 8 language features, someone
will need to add that functionality to ClassDep. Java 9 is due to be
released 2 years later and so we have this maintenance task for writing
new ClassDep code every time there are new language features.
The alternative is use conventions that avoid the need to support and
maintain our own build tool.
I'm suggesting building without classdep.
On 13/02/2014 12:40 AM, Greg Trasuk wrote:
> Hi Peter:
>
> I’m still trying to understand what you’re suggesting. Are you talking specifically about classDepAndJar? When I try to run the build against JDK8-EA, I get an exception in ‘org.objectweb.asm.ClassReader’. Which I suspect could be fixed by a more recent version of asm, although I haven’t tried yet. Basically I suspect the existing build could be made to work without too much effort. As far as supporting JDK8 features, isn’t that just a question of flipping the ‘1.8’ switch on the compiler? And why won’t it work for client code, if the client code doesn’t use ‘classDepAndJar’ (I’ve never used it in client code, for example).
>
> When you say “a new build system”, are you talking about fixing ‘classDepAndJar’, or are you talking about changing to Maven, Gradle, or something else? Are you talking about restructuring the source to make ‘classDepAndJar’ unnecessary, or what? Could you be more specific?
>
> Regards,
>
> Greg Trasuk.
>
> On Feb 12, 2014, at 12:22 AM, Peter<ji...@zeus.net.au> wrote:
>
>> Well, River doesn't build, throws exceptions, it won't work for client code either and it doesn't support Java 8 features.
>>
>> I wrote the java 5 language support code, I would rather spend time reorganising the build once, than maintain a build tool.
>>
>> Just my thoughts.
>>
>> ----- Original message -----
>>> Hi Peter:
>>>
>>> I’m not familiar with Java 8 yet. How is the current build not
>>> supported?
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>> On Feb 11, 2014, at 5:35 AM, Peter<ji...@zeus.net.au> wrote:
>>>
>>>> +1 Peter.
>>>>
>>>> Note that the current build system does not support java 8.
>>>>
>>>> Maintaining a build system is a significant burden ( I know I had to
>>>> implement Java 5 support).
>>>>
>>>> We will need a new build system for java 8, this looks like a step in
>>>> that direction. In reality we need to adopt the build conventions
>>>> used by Rio.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>> ----- Original message -----
>>>>> As discussion has settled somewhat, I would like to call another
>>>>> vote to accept the latest patch described in
>>>>> https://issues.apache.org/jira/browse/RIVER-432
>>>>>
>>>>> The patch removes the archived jar files for Velocity and ASM and
>>>>> replaces them with Apache Ivy scripts that download the jars from
>>>>> Maven Central the first time a build is done. From then on, the
>>>>> jar files are in Ivy’s repository (for more info, see
>>>>> http://ant.apache.org/ivy).
>>>>>
>>>>> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg.
>>>>>
>>>>>
>>>>> On Jan 3, 2014, at 12:57 PM, Greg Trasuk<tr...@stratuscom.com>
>>>>> wrote:
>>>>>
>>>>>> On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG<si...@qcg.nl>
>>>>>> wrote:
>>>>>>
>>>>>>> In order to gain some time to discuss this first i will vote -1.
>>>>>>>
>>>>>>> First, we decided to NOT remove velocity builder.
>>>>>> When I read the email chain, my impression was that we wanted to
>>>>>> remove it (to quote you Sim, “To be honest, I hate it”), but there
>>>>>> was a dependency on it in the ‘extras’ folder that was added in
>>>>>> the trunk branch. As there is no ‘extras’ in the 2.2 branch, and
>>>>>> that is what this patch applies to, I thought it was fair to remove
>>>>>> VelocityConfigurationBuilder from the 2.2 branch. Perhaps we
>>>>>> should revisit the ConfigurationBuilder approach in another
>>>>>> thread. For now I’ll spin another patch that doesn’t remove
>>>>>> VelocityConfigurationBuilder.
>>>>>>
>>>>>>> Second, no need to remove the jars as specified in your own
>>>>>>> comments on RIVER-432.
>>>>>>>
>>>>>>> Pulling in external jars at compile time, shall we start here?
>>>>>>>
>>>>>>> They are already in the svn. They are already in the build
>>>>>>> scripts. What does this patch fix? No legal problems?
>>>>>>>
>>>>>> Apache policy is somewhat unclear on this point. One needs to
>>>>>> examine the mailing lists for clues on what we should really do.
>>>>>> I will argue that:
>>>>>>
>>>>>> 1 - The fundamental distribution model of Apache is source code,
>>>>>> not binaries. 2 - Distributing binaries is tolerated but not
>>>>>> encouraged. Since the svn repository can be seen as a
>>>>>> distribution point, binaries in svn are also tolerated but not
>>>>>> encouraged. 3 - Downloading dependency binaries at build time is
>>>>>> technologically easy, provides the same guarantees as putting them
>>>>>> in cvs, and avoids the question of effectively distributing
>>>>>> someone else’s code.
>>>>>>
>>>>>> All these together suggest that although we’re technically OK to
>>>>>> put dependency jars in a “-deps” package (note that the status quo
>>>>>> _is_ unacceptable - at the very least, we need to restructure the
>>>>>> dependencies into a “-deps” binary package), there is some policy
>>>>>> uncertainty which we avoid totally by having dependencies
>>>>>> downloaded from a known-good source at build time.
>>>>>>
>>>>>> Let’s examine these points:
>>>>>>
>>>>>> 1 - The fundamental distribution model of Apache is source code,
>>>>>> not binaries. Apache began with httpd. Back in those days,
>>>>>> “Open Source” software was distributed in source form only, simply
>>>>>> because it was mostly intended for Unix systems (then later
>>>>>> Linux). I recall the first release of Perl coming down as a
>>>>>> ten-part uunet news message. Part of this distribution model was
>>>>>> practical necessity - System differences made it necessary to
>>>>>> compile your software on the hardware it was going to run on.
>>>>>> Part of it was open-source philosophy. Having the source code
>>>>>> meant that you could take a look at it and verify that it wasn’t
>>>>>> hazardous to your operations.
>>>>>>
>>>>>> In any case, the way we use to use open source software was
>>>>>> (“./configure; make; make install”). If the software had
>>>>>> dependencies, you built them from source, for the same reasons.
>>>>>>
>>>>>> Now, as time has gone on, we’ve gotten used to having the JVM as a
>>>>>> common runtime, and jar files as a common binary distribution
>>>>>> medium. But the Apache Foundation’s mandate is to produce open
>>>>>> source software that is freely usable under the Apache License.
>>>>>> That means source code is at the heart of Apache, despite the rest
>>>>>> of the world’s comfort with binaries. Hence Roy’s statements in
>>>>>> (1):
>>>>>>
>>>>>>> Class files are not open source. Jar files filled with class
>>>>>>> files are not open source. The fact that they are derived from
>>>>>>> open source is applicable only to what we allow projects to be
>>>>>>> dependent upon, not what we vote on as a release package.
>>>>>>> Release votes are on verified open source artifacts. Binary
>>>>>>> packages are separate from source packages. One cannot vote to
>>>>>>> approve a release containing a mix of source and binary code
>>>>>>> because the binary is not open source and cannot be verified to
>>>>>>> be safe for release (even if it was derived from open source).
>>>>>>>
>>>>>>> I thought that was frigging obvious. Why do I need to write
>>>>>>> documentation to explain something that is fundamental to the
>>>>>>> open source definition?
>>>>>> He’s talking about binary packages, not jar files in svn, but I
>>>>>> read that (and many other emails) as a distaste for binary
>>>>>> distributions.
>>>>>>
>>>>>> In fact, if you look at Apache httpd’s download page, it doesn’t
>>>>>> appear that the Apache project publishes any Unix or Linux
>>>>>> binaries. They leave that to other organizations.
>>>>>>
>>>>>> 2 - Distributing binaries is tolerated but not encouraged. Since
>>>>>> the svn repository can be seen as a distribution point, binaries
>>>>>> in svn are also tolerated but not encouraged.
>>>>>>
>>>>>> It’s hard to find a single reference that encapsulates this
>>>>>> outlook, but that’s the impression I get from reading the various
>>>>>> mailing lists. For instance, Sam Ruby says (2):
>>>>>>> IMO, our projects release source. So, our projects should not
>>>>>>> maintain object/binary artifacts in their svn release tree,
>>>>>>> regardless of license (category a or b).
>>>>>> There is some debate on whether the svn tree should be considered a
>>>>>> distribution point. Incubator releases are regularly called out
>>>>>> for not having “NOTICE” and “RELEASE” files at all reasonable
>>>>>> checkout points in svn. [LEGAL-26]
>>>>>> (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and
>>>>>> remains unresolved.
>>>>>>
>>>>>> Doug Cutting (3) says:
>>>>>>> On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
>>>>>>> <st...@gmail.com> wrote:
>>>>>>>> * Source control is not an Apache distribution and hence we do
>>>>>>>> not need to have LICENSE and NOTICE files in source control,
>>>>>>>> it can be a nice convenience, but there is no *requirement*.
>>>>>>> I think perhaps you're looking for clear lines where things are
>>>>>>> actually a bit fuzzy. Certainly releases are official
>>>>>>> distributions and need LICENSE and NOTICE files. That line is
>>>>>>> clear. On the other hand, we try to discourage folks from
>>>>>>> thinking that source control is a distribution. Rather we wish
>>>>>>> it to be considered our shared workspace, containing works in
>>>>>>> progress, not yet always ready for distribution to folks outside
>>>>>>> the foundation. But, since we work in public, folks from
>>>>>>> outside the foundation can see our shared workspace and might
>>>>>>> occasionally mistake it for an official distribution. We'd
>>>>>>> like them to still see a LICENSE and NOTICE file. So it's not
>>>>>>> a hard-and-fast requirement that every tree that can possibly be
>>>>>>> checked out have a LICENSE and NOTICE file at its root, but it's
>>>>>>> a good practice for those trees that are likely to be checked
>>>>>>> out have them, so that folks who might consume them are well
>>>>>>> informed.
>>>>>> Again, he’s not talking directly about jar files in svn, however I
>>>>>> think his statement that “since we work in public, folks from
>>>>>> outside the foundation can see our shared workspace and might
>>>>>> occasionally mistake it for an official distribution” applies
>>>>>> here. Fundamentally, the decision on how and where to distribute
>>>>>> ‘velocity.jar’ rightly belongs with the Velocity group and I don’t
>>>>>> think we ought to redistribute it.
>>>>>>
>>>>>> 3 - Downloading dependency binaries at build time is
>>>>>> technologically easy, provides the same guarantees as putting them
>>>>>> in cvs, and avoids the question of effectively distributing
>>>>>> someone else’s code.
>>>>>>
>>>>>> There doesn’t seem to be clear policy in the ASF on this, as
>>>>>> evidenced by the frequent debates on it, and the lack of
>>>>>> documentation. I’ve tried to lay out an argument that having
>>>>>> jars in svn is not encouraged by the ASF (really, it’s not in line
>>>>>> with the ASF’s charter), even if it isn’t disallowed. You may
>>>>>> disagree, and I won’t claim I’ve made a strong argument, simply
>>>>>> because the policy isn’t clear. So instead of going through
>>>>>> arguments that amount to differences of opinion on Apache policy,
>>>>>> let’s use a technological solution that is simple, common, and
>>>>>> avoids the question altogether, by automatically downloading the
>>>>>> dependencies at build time.
>>>>>>
>>>>>> Projects that use Maven do this automatic download as standard
>>>>>> practice (that’s what Maven does, and that’s what the Maven Central
>>>>>> infrastructure is there to support). We don’t use Maven, which is
>>>>>> fine (our customers have asked us to make our binaries available in
>>>>>> Maven Central, and we’ve done that). Apache Ivy is a popular
>>>>>> add-on to Apache Ant that provides similar dependency resolution
>>>>>> to an Ant-based build.
>>>>>>
>>>>>> I was a little surprised how easy it was to persuade Ivy to get the
>>>>>> required dependencies at build time. The “ivy.xml” file is 39
>>>>>> lines including the ASL header (which by the way I forgot to
>>>>>> include in the patch - I’ll fix that). There are about 50 lines
>>>>>> added to ‘build.xml’ to download Ivy and then download the
>>>>>> required jar files
>>>>>>
>>>>>> So, given that the status-quo seems to be unacceptable (Roy talks
>>>>>> about not having jar files in the open-source trees, only in
>>>>>> “-deps” and “tools” trees), we have two options:
>>>>>>
>>>>>> (a) - restructure the svn repository and the build to allow a
>>>>>> separate “-deps” distribution. This wouldn’t affect our binary
>>>>>> distributions (note that I’m no longer using the term “binary
>>>>>> release”), but to build from source, a user would have to download
>>>>>> a separate archive, unpack it, and then copy those files into the
>>>>>> directory that was unpacked from the source release. This option
>>>>>> effectively still has us distributing dependent binaries, which is
>>>>>> not the goal of the ASF, just with a disclaimer that says “this
>>>>>> isn’t an ASF release, its just a binary distribution put together
>>>>>> by a committer for your convenience, so don’t feel you should
>>>>>> trust it too much”.
>>>>>>
>>>>>> (b) - use Ivy to get the jars from Maven Central automatically as
>>>>>> part of the build.
>>>>>>
>>>>>> I think (b) is the option that causes the least hassle for our
>>>>>> downstream consumers, and not much hassle for us.
>>>>>>
>>>>>>
>>>>>>> Pulling external jars at compile time also makes it more
>>>>>>> difficult to certify the software. In order to certify the
>>>>>>> software you need to establish baseline that will be garanteed
>>>>>>> the same, even if you pull it from the archive 10 years later.
>>>>>> As I said above, Apache’s focus is creating software that can be
>>>>>> built from source, not distributing binaries (note that QCG or
>>>>>> another company might have a different focus, and is perfectly
>>>>>> able to distribute binaries under the Apache license). I think a
>>>>>> reasonably prudent user would ask “How can I trust the
>>>>>> ‘velocity.jar’ that’s included in this binary?” And the answer
>>>>>> would be either “because I built it from source and installed it
>>>>>> in my corporate repository” (very cautious, but not unheard-of) or
>>>>>> “It was published by the Velocity group to a trusted repository,
>>>>>> Maven Central” (more common).
>>>>>>
>>>>>> If you look in the “ivy.xml” file you’ll see that the dependencies
>>>>>> are specified using Maven-style “group-artifact-version”
>>>>>> coordinates. Old versions are maintained in Maven Central
>>>>>> forever. I suppose it’s possible that a publisher could convince
>>>>>> Maven Central to remove a version for some reason (security or
>>>>>> licensing problems perhaps), but then, would we want to be
>>>>>> distributing that version in a “-deps” package?
>>>>>>
>>>>>> I agree that it’s not enough to just say “you need to download
>>>>>> such-and-such jar”, hence the automatic download managed by “Ivy”
>>>>>> from Maven Central.
>>>>>>
>>>>>>> It is not a high level project that builds on several
>>>>>>> frameworks. It is a lowlevel system library. The stuff below the
>>>>>>> stack is minimal. The number of jars we use is limited. Why
>>>>>>> bother?
>>>>>>>
>>>>>> In the currently released branches, the dependencies are limited to
>>>>>> ASM and Velocity. Looking forward to the trunk branch and the
>>>>>> qa_refactor branch, the number of external dependencies seem to be
>>>>>> increasing (IMO I don’t like that, because I also view River as a
>>>>>> low level system library, but I’m only one PMC member). We need
>>>>>> to get in front of the problem before we start distributing large
>>>>>> numbers of dependencies.
>>>>>>
>>>>>> This point rolls in with the general question of jar files in
>>>>>> version control. I was always taught that version control was
>>>>>> for source code, and putting binaries into version control was a
>>>>>> bad idea. In addition, there are practical problems - with older
>>>>>> systems like cvs, even doing an update or commit effectively
>>>>>> downloads the binaries, which slows things down if there are large
>>>>>> binary files. On newer distributed version control systems like
>>>>>> git or Mercurial, the entire repository, including all versions of
>>>>>> binary artifacts, comes down with the project checkout.
>>>>>> Currently, we have one version of relatively few jar files in our
>>>>>> repository, so it’s not a major issue. But it gets worse as time
>>>>>> goes on. So I suggest we work out the technology now to avoid
>>>>>> the problem.
>>>>>>
>>>>>>> Gr. Simon
>>>>>>>
>>>>>> Thanks for the questions, Sim. I hope you’ll come around to
>>>>>> removing your ‘-1’.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> Footnotes
>>>>>> ——————
>>>>>>
>>>>>> (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
>>>>>> (2) - Sam Ruby - http://s.apache.org/r5
>>>>>> (3) - Doug Cutting - http://s.apache.org/GNP
>>>>>>
>>>>>>> On 02-01-14 18:22, Greg Trasuk wrote:
>>>>>>>> Hello all:
>>>>>>>>
>>>>>>>> Please have a look at the patch mentioned below and cast a
>>>>>>>> vote on it.
>>>>>>>>
>>>>>>>> The main idea is to remove the dependency jar files from the
>>>>>>>> source distribution. As a side effect of using Ivy, it
>>>>>>>> becomes reasonable to remove them from the svn archive as
>>>>>>>> well. Also, the Velocity dependency was there to support the
>>>>>>>> VelocityConfigurationBuilder. We had discussed removing that
>>>>>>>> component, so rather than move that dependency to Ivy, I’ve
>>>>>>>> removed VelocityConfigurationBuilder.
>>>>>>>>
>>>>>>>> It’s arguable whether the VelocityConfigurationBuider was part
>>>>>>>> of the official Jini API (I see it as a utility, not API), so
>>>>>>>> I don’t think this commit actually requires a vote. However,
>>>>>>>> it does seem like a significant change to the build process
>>>>>>>> that ought to be reviewed. So I propose to treat this as a
>>>>>>>> “lazy consensus” vote, and will commit the change to the 2.2
>>>>>>>> branch if there are no objections in 72 hours (i.e. 1730UTC
>>>>>>>> 20140105).
>>>>>>>>
>>>>>>>> At the same time, based on discussions over on
>>>>>>>> general@incubator.apache.org, I’ll withdraw my assertion that
>>>>>>>> we can’t have jars in svn. Those interested may want to
>>>>>>>> check out the thread at
>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Greg.
>>>>>>>>
>>>>>>>> On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA)
>>>>>>>> <ji...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> [
>>>>>>>>> https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>>>>>>> ]
>>>>>>>>>
>>>>>>>>> Greg Trasuk updated RIVER-432:
>>>>>>>>> ------------------------------
>>>>>>>>>
>>>>>>>>> Attachment: river-2_2_remove_jars.diff
>>>>>>>>>
>>>>>>>>> The attached patch for the 2.2 branch does the following:
>>>>>>>>> - removes the 'asm' directory and 'tests/lib' directories
>>>>>>>>> which currently contain the asm library, mockito, and junit
>>>>>>>>> jars. - Modifies 'build.xml', 'common.xml', and adds
>>>>>>>>> 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at
>>>>>>>>> build time, and then used to retrieve the libraries
>>>>>>>>> mentioned above from Maven Central. This removes the need
>>>>>>>>> to have the jar files in svn. - Removes (as per discussion
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E)
>>>>>>>>> the VelocityConfigBuilder, and associated Velocity jars.
>>>>>>>>> Note that the 'extras' folder is not present in the 2.2
>>>>>>>>> branch, so Sim's last comments in the thread do not apply.
>>>>>>>>>
>>>>>>>>>> Jar files in svn and src distributions
>>>>>>>>>> --------------------------------------
>>>>>>>>>>
>>>>>>>>>> Key: RIVER-432
>>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-432
>>>>>>>>>> Project: River
>>>>>>>>>> Issue Type: Bug
>>>>>>>>>> Reporter: Greg Trasuk
>>>>>>>>>> Attachments: river-2_2_remove_jars.diff
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Recent traffic on the incubator lists has pointed out that
>>>>>>>>>> including jar files for dependencies in the subversion
>>>>>>>>>> repository and the source distributions is against Apache
>>>>>>>>>> policy. In River, the following libraries appear in the
>>>>>>>>>> Subversion repository and the source distributions (these
>>>>>>>>>> are from trunk, a smaller set appear in the 2.2 branch):
>>>>>>>>>> animal-sniffer asm bouncy-castle dnsjava high-scale-lib
>>>>>>>>>> rc-libs
>>>>>>>>>> velocity
>>>>>>>>>> They all have to go. What are we using them for? As I
>>>>>>>>>> understand it, we were going to remove the
>>>>>>>>>> VelocityConfigurationBuilder, so that's not a problem.
>>>>>>>>>> Some of the others are available from Maven Central, so we
>>>>>>>>>> can get them at build time using Ivy or another build
>>>>>>>>>> tool. Which ones are actually required? And where did
>>>>>>>>>> they come from?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> This message was sent by Atlassian JIRA
>>>>>>>>> (v6.1.5#6160)
>>>>>>>
>>>>>>> --
>>>>>>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>>>>>>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag:
>>>>>>> 28088397
Re: Build system and Java 8 was: Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Peter:
I’m still trying to understand what you’re suggesting. Are you talking specifically about classDepAndJar? When I try to run the build against JDK8-EA, I get an exception in ‘org.objectweb.asm.ClassReader’. Which I suspect could be fixed by a more recent version of asm, although I haven’t tried yet. Basically I suspect the existing build could be made to work without too much effort. As far as supporting JDK8 features, isn’t that just a question of flipping the ‘1.8’ switch on the compiler? And why won’t it work for client code, if the client code doesn’t use ‘classDepAndJar’ (I’ve never used it in client code, for example).
When you say “a new build system”, are you talking about fixing ‘classDepAndJar’, or are you talking about changing to Maven, Gradle, or something else? Are you talking about restructuring the source to make ‘classDepAndJar’ unnecessary, or what? Could you be more specific?
Regards,
Greg Trasuk.
On Feb 12, 2014, at 12:22 AM, Peter <ji...@zeus.net.au> wrote:
> Well, River doesn't build, throws exceptions, it won't work for client code either and it doesn't support Java 8 features.
>
> I wrote the java 5 language support code, I would rather spend time reorganising the build once, than maintain a build tool.
>
> Just my thoughts.
>
> ----- Original message -----
>>
>> Hi Peter:
>>
>> I’m not familiar with Java 8 yet. How is the current build not
>> supported?
>>
>> Cheers,
>>
>> Greg.
>>
>> On Feb 11, 2014, at 5:35 AM, Peter <ji...@zeus.net.au> wrote:
>>
>>> +1 Peter.
>>>
>>> Note that the current build system does not support java 8.
>>>
>>> Maintaining a build system is a significant burden ( I know I had to
>>> implement Java 5 support).
>>>
>>> We will need a new build system for java 8, this looks like a step in
>>> that direction. In reality we need to adopt the build conventions
>>> used by Rio.
>>>
>>> Regards,
>>>
>>> Peter.
>>> ----- Original message -----
>>>>
>>>> As discussion has settled somewhat, I would like to call another
>>>> vote to accept the latest patch described in
>>>> https://issues.apache.org/jira/browse/RIVER-432
>>>>
>>>> The patch removes the archived jar files for Velocity and ASM and
>>>> replaces them with Apache Ivy scripts that download the jars from
>>>> Maven Central the first time a build is done. From then on, the
>>>> jar files are in Ivy’s repository (for more info, see
>>>> http://ant.apache.org/ivy).
>>>>
>>>> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>>>>
>>>> Cheers,
>>>>
>>>> Greg.
>>>>
>>>>
>>>> On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl>
>>>>> wrote:
>>>>>
>>>>>> In order to gain some time to discuss this first i will vote -1.
>>>>>>
>>>>>> First, we decided to NOT remove velocity builder.
>>>>>
>>>>> When I read the email chain, my impression was that we wanted to
>>>>> remove it (to quote you Sim, “To be honest, I hate it”), but there
>>>>> was a dependency on it in the ‘extras’ folder that was added in
>>>>> the trunk branch. As there is no ‘extras’ in the 2.2 branch, and
>>>>> that is what this patch applies to, I thought it was fair to remove
>>>>> VelocityConfigurationBuilder from the 2.2 branch. Perhaps we
>>>>> should revisit the ConfigurationBuilder approach in another
>>>>> thread. For now I’ll spin another patch that doesn’t remove
>>>>> VelocityConfigurationBuilder.
>>>>>
>>>>>>
>>>>>> Second, no need to remove the jars as specified in your own
>>>>>> comments on RIVER-432.
>>>>>>
>>>>>> Pulling in external jars at compile time, shall we start here?
>>>>>>
>>>>>> They are already in the svn. They are already in the build
>>>>>> scripts. What does this patch fix? No legal problems?
>>>>>>
>>>>>
>>>>> Apache policy is somewhat unclear on this point. One needs to
>>>>> examine the mailing lists for clues on what we should really do.
>>>>> I will argue that:
>>>>>
>>>>> 1 - The fundamental distribution model of Apache is source code,
>>>>> not binaries. 2 - Distributing binaries is tolerated but not
>>>>> encouraged. Since the svn repository can be seen as a
>>>>> distribution point, binaries in svn are also tolerated but not
>>>>> encouraged. 3 - Downloading dependency binaries at build time is
>>>>> technologically easy, provides the same guarantees as putting them
>>>>> in cvs, and avoids the question of effectively distributing
>>>>> someone else’s code.
>>>>>
>>>>> All these together suggest that although we’re technically OK to
>>>>> put dependency jars in a “-deps” package (note that the status quo
>>>>> _is_ unacceptable - at the very least, we need to restructure the
>>>>> dependencies into a “-deps” binary package), there is some policy
>>>>> uncertainty which we avoid totally by having dependencies
>>>>> downloaded from a known-good source at build time.
>>>>>
>>>>> Let’s examine these points:
>>>>>
>>>>> 1 - The fundamental distribution model of Apache is source code,
>>>>> not binaries. Apache began with httpd. Back in those days,
>>>>> “Open Source” software was distributed in source form only, simply
>>>>> because it was mostly intended for Unix systems (then later
>>>>> Linux). I recall the first release of Perl coming down as a
>>>>> ten-part uunet news message. Part of this distribution model was
>>>>> practical necessity - System differences made it necessary to
>>>>> compile your software on the hardware it was going to run on.
>>>>> Part of it was open-source philosophy. Having the source code
>>>>> meant that you could take a look at it and verify that it wasn’t
>>>>> hazardous to your operations.
>>>>>
>>>>> In any case, the way we use to use open source software was
>>>>> (“./configure; make; make install”). If the software had
>>>>> dependencies, you built them from source, for the same reasons.
>>>>>
>>>>> Now, as time has gone on, we’ve gotten used to having the JVM as a
>>>>> common runtime, and jar files as a common binary distribution
>>>>> medium. But the Apache Foundation’s mandate is to produce open
>>>>> source software that is freely usable under the Apache License.
>>>>> That means source code is at the heart of Apache, despite the rest
>>>>> of the world’s comfort with binaries. Hence Roy’s statements in
>>>>> (1):
>>>>>
>>>>>> Class files are not open source. Jar files filled with class
>>>>>> files are not open source. The fact that they are derived from
>>>>>> open source is applicable only to what we allow projects to be
>>>>>> dependent upon, not what we vote on as a release package.
>>>>>> Release votes are on verified open source artifacts. Binary
>>>>>> packages are separate from source packages. One cannot vote to
>>>>>> approve a release containing a mix of source and binary code
>>>>>> because the binary is not open source and cannot be verified to
>>>>>> be safe for release (even if it was derived from open source).
>>>>>>
>>>>>> I thought that was frigging obvious. Why do I need to write
>>>>>> documentation to explain something that is fundamental to the
>>>>>> open source definition?
>>>>> He’s talking about binary packages, not jar files in svn, but I
>>>>> read that (and many other emails) as a distaste for binary
>>>>> distributions.
>>>>>
>>>>> In fact, if you look at Apache httpd’s download page, it doesn’t
>>>>> appear that the Apache project publishes any Unix or Linux
>>>>> binaries. They leave that to other organizations.
>>>>>
>>>>> 2 - Distributing binaries is tolerated but not encouraged. Since
>>>>> the svn repository can be seen as a distribution point, binaries
>>>>> in svn are also tolerated but not encouraged.
>>>>>
>>>>> It’s hard to find a single reference that encapsulates this
>>>>> outlook, but that’s the impression I get from reading the various
>>>>> mailing lists. For instance, Sam Ruby says (2):
>>>>>> IMO, our projects release source. So, our projects should not
>>>>>> maintain object/binary artifacts in their svn release tree,
>>>>>> regardless of license (category a or b).
>>>>> There is some debate on whether the svn tree should be considered a
>>>>> distribution point. Incubator releases are regularly called out
>>>>> for not having “NOTICE” and “RELEASE” files at all reasonable
>>>>> checkout points in svn. [LEGAL-26]
>>>>> (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and
>>>>> remains unresolved.
>>>>>
>>>>> Doug Cutting (3) says:
>>>>>> On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
>>>>>> <st...@gmail.com> wrote:
>>>>>>> * Source control is not an Apache distribution and hence we do
>>>>>>> not need to have LICENSE and NOTICE files in source control,
>>>>>>> it can be a nice convenience, but there is no *requirement*.
>>>>>>
>>>>>> I think perhaps you're looking for clear lines where things are
>>>>>> actually a bit fuzzy. Certainly releases are official
>>>>>> distributions and need LICENSE and NOTICE files. That line is
>>>>>> clear. On the other hand, we try to discourage folks from
>>>>>> thinking that source control is a distribution. Rather we wish
>>>>>> it to be considered our shared workspace, containing works in
>>>>>> progress, not yet always ready for distribution to folks outside
>>>>>> the foundation. But, since we work in public, folks from
>>>>>> outside the foundation can see our shared workspace and might
>>>>>> occasionally mistake it for an official distribution. We'd
>>>>>> like them to still see a LICENSE and NOTICE file. So it's not
>>>>>> a hard-and-fast requirement that every tree that can possibly be
>>>>>> checked out have a LICENSE and NOTICE file at its root, but it's
>>>>>> a good practice for those trees that are likely to be checked
>>>>>> out have them, so that folks who might consume them are well
>>>>>> informed.
>>>>> Again, he’s not talking directly about jar files in svn, however I
>>>>> think his statement that “since we work in public, folks from
>>>>> outside the foundation can see our shared workspace and might
>>>>> occasionally mistake it for an official distribution” applies
>>>>> here. Fundamentally, the decision on how and where to distribute
>>>>> ‘velocity.jar’ rightly belongs with the Velocity group and I don’t
>>>>> think we ought to redistribute it.
>>>>>
>>>>> 3 - Downloading dependency binaries at build time is
>>>>> technologically easy, provides the same guarantees as putting them
>>>>> in cvs, and avoids the question of effectively distributing
>>>>> someone else’s code.
>>>>>
>>>>> There doesn’t seem to be clear policy in the ASF on this, as
>>>>> evidenced by the frequent debates on it, and the lack of
>>>>> documentation. I’ve tried to lay out an argument that having
>>>>> jars in svn is not encouraged by the ASF (really, it’s not in line
>>>>> with the ASF’s charter), even if it isn’t disallowed. You may
>>>>> disagree, and I won’t claim I’ve made a strong argument, simply
>>>>> because the policy isn’t clear. So instead of going through
>>>>> arguments that amount to differences of opinion on Apache policy,
>>>>> let’s use a technological solution that is simple, common, and
>>>>> avoids the question altogether, by automatically downloading the
>>>>> dependencies at build time.
>>>>>
>>>>> Projects that use Maven do this automatic download as standard
>>>>> practice (that’s what Maven does, and that’s what the Maven Central
>>>>> infrastructure is there to support). We don’t use Maven, which is
>>>>> fine (our customers have asked us to make our binaries available in
>>>>> Maven Central, and we’ve done that). Apache Ivy is a popular
>>>>> add-on to Apache Ant that provides similar dependency resolution
>>>>> to an Ant-based build.
>>>>>
>>>>> I was a little surprised how easy it was to persuade Ivy to get the
>>>>> required dependencies at build time. The “ivy.xml” file is 39
>>>>> lines including the ASL header (which by the way I forgot to
>>>>> include in the patch - I’ll fix that). There are about 50 lines
>>>>> added to ‘build.xml’ to download Ivy and then download the
>>>>> required jar files
>>>>>
>>>>> So, given that the status-quo seems to be unacceptable (Roy talks
>>>>> about not having jar files in the open-source trees, only in
>>>>> “-deps” and “tools” trees), we have two options:
>>>>>
>>>>> (a) - restructure the svn repository and the build to allow a
>>>>> separate “-deps” distribution. This wouldn’t affect our binary
>>>>> distributions (note that I’m no longer using the term “binary
>>>>> release”), but to build from source, a user would have to download
>>>>> a separate archive, unpack it, and then copy those files into the
>>>>> directory that was unpacked from the source release. This option
>>>>> effectively still has us distributing dependent binaries, which is
>>>>> not the goal of the ASF, just with a disclaimer that says “this
>>>>> isn’t an ASF release, its just a binary distribution put together
>>>>> by a committer for your convenience, so don’t feel you should
>>>>> trust it too much”.
>>>>>
>>>>> (b) - use Ivy to get the jars from Maven Central automatically as
>>>>> part of the build.
>>>>>
>>>>> I think (b) is the option that causes the least hassle for our
>>>>> downstream consumers, and not much hassle for us.
>>>>>
>>>>>
>>>>>> Pulling external jars at compile time also makes it more
>>>>>> difficult to certify the software. In order to certify the
>>>>>> software you need to establish baseline that will be garanteed
>>>>>> the same, even if you pull it from the archive 10 years later.
>>>>>
>>>>> As I said above, Apache’s focus is creating software that can be
>>>>> built from source, not distributing binaries (note that QCG or
>>>>> another company might have a different focus, and is perfectly
>>>>> able to distribute binaries under the Apache license). I think a
>>>>> reasonably prudent user would ask “How can I trust the
>>>>> ‘velocity.jar’ that’s included in this binary?” And the answer
>>>>> would be either “because I built it from source and installed it
>>>>> in my corporate repository” (very cautious, but not unheard-of) or
>>>>> “It was published by the Velocity group to a trusted repository,
>>>>> Maven Central” (more common).
>>>>>
>>>>> If you look in the “ivy.xml” file you’ll see that the dependencies
>>>>> are specified using Maven-style “group-artifact-version”
>>>>> coordinates. Old versions are maintained in Maven Central
>>>>> forever. I suppose it’s possible that a publisher could convince
>>>>> Maven Central to remove a version for some reason (security or
>>>>> licensing problems perhaps), but then, would we want to be
>>>>> distributing that version in a “-deps” package?
>>>>>
>>>>> I agree that it’s not enough to just say “you need to download
>>>>> such-and-such jar”, hence the automatic download managed by “Ivy”
>>>>> from Maven Central.
>>>>>
>>>>>> It is not a high level project that builds on several
>>>>>> frameworks. It is a lowlevel system library. The stuff below the
>>>>>> stack is minimal. The number of jars we use is limited. Why
>>>>>> bother?
>>>>>>
>>>>>
>>>>> In the currently released branches, the dependencies are limited to
>>>>> ASM and Velocity. Looking forward to the trunk branch and the
>>>>> qa_refactor branch, the number of external dependencies seem to be
>>>>> increasing (IMO I don’t like that, because I also view River as a
>>>>> low level system library, but I’m only one PMC member). We need
>>>>> to get in front of the problem before we start distributing large
>>>>> numbers of dependencies.
>>>>>
>>>>> This point rolls in with the general question of jar files in
>>>>> version control. I was always taught that version control was
>>>>> for source code, and putting binaries into version control was a
>>>>> bad idea. In addition, there are practical problems - with older
>>>>> systems like cvs, even doing an update or commit effectively
>>>>> downloads the binaries, which slows things down if there are large
>>>>> binary files. On newer distributed version control systems like
>>>>> git or Mercurial, the entire repository, including all versions of
>>>>> binary artifacts, comes down with the project checkout.
>>>>> Currently, we have one version of relatively few jar files in our
>>>>> repository, so it’s not a major issue. But it gets worse as time
>>>>> goes on. So I suggest we work out the technology now to avoid
>>>>> the problem.
>>>>>
>>>>>> Gr. Simon
>>>>>>
>>>>>
>>>>> Thanks for the questions, Sim. I hope you’ll come around to
>>>>> removing your ‘-1’.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg
>>>>>
>>>>> Footnotes
>>>>> ——————
>>>>>
>>>>> (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
>>>>> (2) - Sam Ruby - http://s.apache.org/r5
>>>>> (3) - Doug Cutting - http://s.apache.org/GNP
>>>>>
>>>>>> On 02-01-14 18:22, Greg Trasuk wrote:
>>>>>>>
>>>>>>> Hello all:
>>>>>>>
>>>>>>> Please have a look at the patch mentioned below and cast a
>>>>>>> vote on it.
>>>>>>>
>>>>>>> The main idea is to remove the dependency jar files from the
>>>>>>> source distribution. As a side effect of using Ivy, it
>>>>>>> becomes reasonable to remove them from the svn archive as
>>>>>>> well. Also, the Velocity dependency was there to support the
>>>>>>> VelocityConfigurationBuilder. We had discussed removing that
>>>>>>> component, so rather than move that dependency to Ivy, I’ve
>>>>>>> removed VelocityConfigurationBuilder.
>>>>>>>
>>>>>>> It’s arguable whether the VelocityConfigurationBuider was part
>>>>>>> of the official Jini API (I see it as a utility, not API), so
>>>>>>> I don’t think this commit actually requires a vote. However,
>>>>>>> it does seem like a significant change to the build process
>>>>>>> that ought to be reviewed. So I propose to treat this as a
>>>>>>> “lazy consensus” vote, and will commit the change to the 2.2
>>>>>>> branch if there are no objections in 72 hours (i.e. 1730UTC
>>>>>>> 20140105).
>>>>>>>
>>>>>>> At the same time, based on discussions over on
>>>>>>> general@incubator.apache.org, I’ll withdraw my assertion that
>>>>>>> we can’t have jars in svn. Those interested may want to
>>>>>>> check out the thread at
>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Greg.
>>>>>>>
>>>>>>> On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA)
>>>>>>> <ji...@apache.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> [
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Greg Trasuk updated RIVER-432:
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> Attachment: river-2_2_remove_jars.diff
>>>>>>>>
>>>>>>>> The attached patch for the 2.2 branch does the following:
>>>>>>>> - removes the 'asm' directory and 'tests/lib' directories
>>>>>>>> which currently contain the asm library, mockito, and junit
>>>>>>>> jars. - Modifies 'build.xml', 'common.xml', and adds
>>>>>>>> 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at
>>>>>>>> build time, and then used to retrieve the libraries
>>>>>>>> mentioned above from Maven Central. This removes the need
>>>>>>>> to have the jar files in svn. - Removes (as per discussion
>>>>>>>> http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E)
>>>>>>>> the VelocityConfigBuilder, and associated Velocity jars.
>>>>>>>> Note that the 'extras' folder is not present in the 2.2
>>>>>>>> branch, so Sim's last comments in the thread do not apply.
>>>>>>>>
>>>>>>>>> Jar files in svn and src distributions
>>>>>>>>> --------------------------------------
>>>>>>>>>
>>>>>>>>> Key: RIVER-432
>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-432
>>>>>>>>> Project: River
>>>>>>>>> Issue Type: Bug
>>>>>>>>> Reporter: Greg Trasuk
>>>>>>>>> Attachments: river-2_2_remove_jars.diff
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Recent traffic on the incubator lists has pointed out that
>>>>>>>>> including jar files for dependencies in the subversion
>>>>>>>>> repository and the source distributions is against Apache
>>>>>>>>> policy. In River, the following libraries appear in the
>>>>>>>>> Subversion repository and the source distributions (these
>>>>>>>>> are from trunk, a smaller set appear in the 2.2 branch):
>>>>>>>>> animal-sniffer asm bouncy-castle dnsjava high-scale-lib
>>>>>>>>> rc-libs
>>>>>>>>> velocity
>>>>>>>>> They all have to go. What are we using them for? As I
>>>>>>>>> understand it, we were going to remove the
>>>>>>>>> VelocityConfigurationBuilder, so that's not a problem.
>>>>>>>>> Some of the others are available from Maven Central, so we
>>>>>>>>> can get them at build time using Ivy or another build
>>>>>>>>> tool. Which ones are actually required? And where did
>>>>>>>>> they come from?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> This message was sent by Atlassian JIRA
>>>>>>>> (v6.1.5#6160)
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>>>>>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag:
>>>>>> 28088397
>>>>>
>>>>
>>>
>>
>
Re: Build system and Java 8 was: Re: [Vote] (RIVER-432) Jar files
in svn and src distributions
Posted by Peter <ji...@zeus.net.au>.
Well, River doesn't build, throws exceptions, it won't work for client code either and it doesn't support Java 8 features.
I wrote the java 5 language support code, I would rather spend time reorganising the build once, than maintain a build tool.
Just my thoughts.
----- Original message -----
>
> Hi Peter:
>
> I’m not familiar with Java 8 yet. How is the current build not
> supported?
>
> Cheers,
>
> Greg.
>
> On Feb 11, 2014, at 5:35 AM, Peter <ji...@zeus.net.au> wrote:
>
> > +1 Peter.
> >
> > Note that the current build system does not support java 8.
> >
> > Maintaining a build system is a significant burden ( I know I had to
> > implement Java 5 support).
> >
> > We will need a new build system for java 8, this looks like a step in
> > that direction. In reality we need to adopt the build conventions
> > used by Rio.
> >
> > Regards,
> >
> > Peter.
> > ----- Original message -----
> > >
> > > As discussion has settled somewhat, I would like to call another
> > > vote to accept the latest patch described in
> > > https://issues.apache.org/jira/browse/RIVER-432
> > >
> > > The patch removes the archived jar files for Velocity and ASM and
> > > replaces them with Apache Ivy scripts that download the jars from
> > > Maven Central the first time a build is done. From then on, the
> > > jar files are in Ivy’s repository (for more info, see
> > > http://ant.apache.org/ivy).
> > >
> > > Voting will remain open at least until 2000 UTC Feb 13, 2014.
> > >
> > > Cheers,
> > >
> > > Greg.
> > >
> > >
> > > On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com>
> > > wrote:
> > >
> > > >
> > > > On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl>
> > > > wrote:
> > > >
> > > > > In order to gain some time to discuss this first i will vote -1.
> > > > >
> > > > > First, we decided to NOT remove velocity builder.
> > > >
> > > > When I read the email chain, my impression was that we wanted to
> > > > remove it (to quote you Sim, “To be honest, I hate it”), but there
> > > > was a dependency on it in the ‘extras’ folder that was added in
> > > > the trunk branch. As there is no ‘extras’ in the 2.2 branch, and
> > > > that is what this patch applies to, I thought it was fair to remove
> > > > VelocityConfigurationBuilder from the 2.2 branch. Perhaps we
> > > > should revisit the ConfigurationBuilder approach in another
> > > > thread. For now I’ll spin another patch that doesn’t remove
> > > > VelocityConfigurationBuilder.
> > > >
> > > > >
> > > > > Second, no need to remove the jars as specified in your own
> > > > > comments on RIVER-432.
> > > > >
> > > > > Pulling in external jars at compile time, shall we start here?
> > > > >
> > > > > They are already in the svn. They are already in the build
> > > > > scripts. What does this patch fix? No legal problems?
> > > > >
> > > >
> > > > Apache policy is somewhat unclear on this point. One needs to
> > > > examine the mailing lists for clues on what we should really do.
> > > > I will argue that:
> > > >
> > > > 1 - The fundamental distribution model of Apache is source code,
> > > > not binaries. 2 - Distributing binaries is tolerated but not
> > > > encouraged. Since the svn repository can be seen as a
> > > > distribution point, binaries in svn are also tolerated but not
> > > > encouraged. 3 - Downloading dependency binaries at build time is
> > > > technologically easy, provides the same guarantees as putting them
> > > > in cvs, and avoids the question of effectively distributing
> > > > someone else’s code.
> > > >
> > > > All these together suggest that although we’re technically OK to
> > > > put dependency jars in a “-deps” package (note that the status quo
> > > > _is_ unacceptable - at the very least, we need to restructure the
> > > > dependencies into a “-deps” binary package), there is some policy
> > > > uncertainty which we avoid totally by having dependencies
> > > > downloaded from a known-good source at build time.
> > > >
> > > > Let’s examine these points:
> > > >
> > > > 1 - The fundamental distribution model of Apache is source code,
> > > > not binaries. Apache began with httpd. Back in those days,
> > > > “Open Source” software was distributed in source form only, simply
> > > > because it was mostly intended for Unix systems (then later
> > > > Linux). I recall the first release of Perl coming down as a
> > > > ten-part uunet news message. Part of this distribution model was
> > > > practical necessity - System differences made it necessary to
> > > > compile your software on the hardware it was going to run on.
> > > > Part of it was open-source philosophy. Having the source code
> > > > meant that you could take a look at it and verify that it wasn’t
> > > > hazardous to your operations.
> > > >
> > > > In any case, the way we use to use open source software was
> > > > (“./configure; make; make install”). If the software had
> > > > dependencies, you built them from source, for the same reasons.
> > > >
> > > > Now, as time has gone on, we’ve gotten used to having the JVM as a
> > > > common runtime, and jar files as a common binary distribution
> > > > medium. But the Apache Foundation’s mandate is to produce open
> > > > source software that is freely usable under the Apache License.
> > > > That means source code is at the heart of Apache, despite the rest
> > > > of the world’s comfort with binaries. Hence Roy’s statements in
> > > > (1):
> > > >
> > > > > Class files are not open source. Jar files filled with class
> > > > > files are not open source. The fact that they are derived from
> > > > > open source is applicable only to what we allow projects to be
> > > > > dependent upon, not what we vote on as a release package.
> > > > > Release votes are on verified open source artifacts. Binary
> > > > > packages are separate from source packages. One cannot vote to
> > > > > approve a release containing a mix of source and binary code
> > > > > because the binary is not open source and cannot be verified to
> > > > > be safe for release (even if it was derived from open source).
> > > > >
> > > > > I thought that was frigging obvious. Why do I need to write
> > > > > documentation to explain something that is fundamental to the
> > > > > open source definition?
> > > > He’s talking about binary packages, not jar files in svn, but I
> > > > read that (and many other emails) as a distaste for binary
> > > > distributions.
> > > >
> > > > In fact, if you look at Apache httpd’s download page, it doesn’t
> > > > appear that the Apache project publishes any Unix or Linux
> > > > binaries. They leave that to other organizations.
> > > >
> > > > 2 - Distributing binaries is tolerated but not encouraged. Since
> > > > the svn repository can be seen as a distribution point, binaries
> > > > in svn are also tolerated but not encouraged.
> > > >
> > > > It’s hard to find a single reference that encapsulates this
> > > > outlook, but that’s the impression I get from reading the various
> > > > mailing lists. For instance, Sam Ruby says (2):
> > > > > IMO, our projects release source. So, our projects should not
> > > > > maintain object/binary artifacts in their svn release tree,
> > > > > regardless of license (category a or b).
> > > > There is some debate on whether the svn tree should be considered a
> > > > distribution point. Incubator releases are regularly called out
> > > > for not having “NOTICE” and “RELEASE” files at all reasonable
> > > > checkout points in svn. [LEGAL-26]
> > > > (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and
> > > > remains unresolved.
> > > >
> > > > Doug Cutting (3) says:
> > > > > On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
> > > > > <st...@gmail.com> wrote:
> > > > > > * Source control is not an Apache distribution and hence we do
> > > > > > not need to have LICENSE and NOTICE files in source control,
> > > > > > it can be a nice convenience, but there is no *requirement*.
> > > > >
> > > > > I think perhaps you're looking for clear lines where things are
> > > > > actually a bit fuzzy. Certainly releases are official
> > > > > distributions and need LICENSE and NOTICE files. That line is
> > > > > clear. On the other hand, we try to discourage folks from
> > > > > thinking that source control is a distribution. Rather we wish
> > > > > it to be considered our shared workspace, containing works in
> > > > > progress, not yet always ready for distribution to folks outside
> > > > > the foundation. But, since we work in public, folks from
> > > > > outside the foundation can see our shared workspace and might
> > > > > occasionally mistake it for an official distribution. We'd
> > > > > like them to still see a LICENSE and NOTICE file. So it's not
> > > > > a hard-and-fast requirement that every tree that can possibly be
> > > > > checked out have a LICENSE and NOTICE file at its root, but it's
> > > > > a good practice for those trees that are likely to be checked
> > > > > out have them, so that folks who might consume them are well
> > > > > informed.
> > > > Again, he’s not talking directly about jar files in svn, however I
> > > > think his statement that “since we work in public, folks from
> > > > outside the foundation can see our shared workspace and might
> > > > occasionally mistake it for an official distribution” applies
> > > > here. Fundamentally, the decision on how and where to distribute
> > > > ‘velocity.jar’ rightly belongs with the Velocity group and I don’t
> > > > think we ought to redistribute it.
> > > >
> > > > 3 - Downloading dependency binaries at build time is
> > > > technologically easy, provides the same guarantees as putting them
> > > > in cvs, and avoids the question of effectively distributing
> > > > someone else’s code.
> > > >
> > > > There doesn’t seem to be clear policy in the ASF on this, as
> > > > evidenced by the frequent debates on it, and the lack of
> > > > documentation. I’ve tried to lay out an argument that having
> > > > jars in svn is not encouraged by the ASF (really, it’s not in line
> > > > with the ASF’s charter), even if it isn’t disallowed. You may
> > > > disagree, and I won’t claim I’ve made a strong argument, simply
> > > > because the policy isn’t clear. So instead of going through
> > > > arguments that amount to differences of opinion on Apache policy,
> > > > let’s use a technological solution that is simple, common, and
> > > > avoids the question altogether, by automatically downloading the
> > > > dependencies at build time.
> > > >
> > > > Projects that use Maven do this automatic download as standard
> > > > practice (that’s what Maven does, and that’s what the Maven Central
> > > > infrastructure is there to support). We don’t use Maven, which is
> > > > fine (our customers have asked us to make our binaries available in
> > > > Maven Central, and we’ve done that). Apache Ivy is a popular
> > > > add-on to Apache Ant that provides similar dependency resolution
> > > > to an Ant-based build.
> > > >
> > > > I was a little surprised how easy it was to persuade Ivy to get the
> > > > required dependencies at build time. The “ivy.xml” file is 39
> > > > lines including the ASL header (which by the way I forgot to
> > > > include in the patch - I’ll fix that). There are about 50 lines
> > > > added to ‘build.xml’ to download Ivy and then download the
> > > > required jar files
> > > >
> > > > So, given that the status-quo seems to be unacceptable (Roy talks
> > > > about not having jar files in the open-source trees, only in
> > > > “-deps” and “tools” trees), we have two options:
> > > >
> > > > (a) - restructure the svn repository and the build to allow a
> > > > separate “-deps” distribution. This wouldn’t affect our binary
> > > > distributions (note that I’m no longer using the term “binary
> > > > release”), but to build from source, a user would have to download
> > > > a separate archive, unpack it, and then copy those files into the
> > > > directory that was unpacked from the source release. This option
> > > > effectively still has us distributing dependent binaries, which is
> > > > not the goal of the ASF, just with a disclaimer that says “this
> > > > isn’t an ASF release, its just a binary distribution put together
> > > > by a committer for your convenience, so don’t feel you should
> > > > trust it too much”.
> > > >
> > > > (b) - use Ivy to get the jars from Maven Central automatically as
> > > > part of the build.
> > > >
> > > > I think (b) is the option that causes the least hassle for our
> > > > downstream consumers, and not much hassle for us.
> > > >
> > > >
> > > > > Pulling external jars at compile time also makes it more
> > > > > difficult to certify the software. In order to certify the
> > > > > software you need to establish baseline that will be garanteed
> > > > > the same, even if you pull it from the archive 10 years later.
> > > >
> > > > As I said above, Apache’s focus is creating software that can be
> > > > built from source, not distributing binaries (note that QCG or
> > > > another company might have a different focus, and is perfectly
> > > > able to distribute binaries under the Apache license). I think a
> > > > reasonably prudent user would ask “How can I trust the
> > > > ‘velocity.jar’ that’s included in this binary?” And the answer
> > > > would be either “because I built it from source and installed it
> > > > in my corporate repository” (very cautious, but not unheard-of) or
> > > > “It was published by the Velocity group to a trusted repository,
> > > > Maven Central” (more common).
> > > >
> > > > If you look in the “ivy.xml” file you’ll see that the dependencies
> > > > are specified using Maven-style “group-artifact-version”
> > > > coordinates. Old versions are maintained in Maven Central
> > > > forever. I suppose it’s possible that a publisher could convince
> > > > Maven Central to remove a version for some reason (security or
> > > > licensing problems perhaps), but then, would we want to be
> > > > distributing that version in a “-deps” package?
> > > >
> > > > I agree that it’s not enough to just say “you need to download
> > > > such-and-such jar”, hence the automatic download managed by “Ivy”
> > > > from Maven Central.
> > > >
> > > > > It is not a high level project that builds on several
> > > > > frameworks. It is a lowlevel system library. The stuff below the
> > > > > stack is minimal. The number of jars we use is limited. Why
> > > > > bother?
> > > > >
> > > >
> > > > In the currently released branches, the dependencies are limited to
> > > > ASM and Velocity. Looking forward to the trunk branch and the
> > > > qa_refactor branch, the number of external dependencies seem to be
> > > > increasing (IMO I don’t like that, because I also view River as a
> > > > low level system library, but I’m only one PMC member). We need
> > > > to get in front of the problem before we start distributing large
> > > > numbers of dependencies.
> > > >
> > > > This point rolls in with the general question of jar files in
> > > > version control. I was always taught that version control was
> > > > for source code, and putting binaries into version control was a
> > > > bad idea. In addition, there are practical problems - with older
> > > > systems like cvs, even doing an update or commit effectively
> > > > downloads the binaries, which slows things down if there are large
> > > > binary files. On newer distributed version control systems like
> > > > git or Mercurial, the entire repository, including all versions of
> > > > binary artifacts, comes down with the project checkout.
> > > > Currently, we have one version of relatively few jar files in our
> > > > repository, so it’s not a major issue. But it gets worse as time
> > > > goes on. So I suggest we work out the technology now to avoid
> > > > the problem.
> > > >
> > > > > Gr. Simon
> > > > >
> > > >
> > > > Thanks for the questions, Sim. I hope you’ll come around to
> > > > removing your ‘-1’.
> > > >
> > > > Cheers,
> > > >
> > > > Greg
> > > >
> > > > Footnotes
> > > > ——————
> > > >
> > > > (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
> > > > (2) - Sam Ruby - http://s.apache.org/r5
> > > > (3) - Doug Cutting - http://s.apache.org/GNP
> > > >
> > > > > On 02-01-14 18:22, Greg Trasuk wrote:
> > > > > >
> > > > > > Hello all:
> > > > > >
> > > > > > Please have a look at the patch mentioned below and cast a
> > > > > > vote on it.
> > > > > >
> > > > > > The main idea is to remove the dependency jar files from the
> > > > > > source distribution. As a side effect of using Ivy, it
> > > > > > becomes reasonable to remove them from the svn archive as
> > > > > > well. Also, the Velocity dependency was there to support the
> > > > > > VelocityConfigurationBuilder. We had discussed removing that
> > > > > > component, so rather than move that dependency to Ivy, I’ve
> > > > > > removed VelocityConfigurationBuilder.
> > > > > >
> > > > > > It’s arguable whether the VelocityConfigurationBuider was part
> > > > > > of the official Jini API (I see it as a utility, not API), so
> > > > > > I don’t think this commit actually requires a vote. However,
> > > > > > it does seem like a significant change to the build process
> > > > > > that ought to be reviewed. So I propose to treat this as a
> > > > > > “lazy consensus” vote, and will commit the change to the 2.2
> > > > > > branch if there are no objections in 72 hours (i.e. 1730UTC
> > > > > > 20140105).
> > > > > >
> > > > > > At the same time, based on discussions over on
> > > > > > general@incubator.apache.org, I’ll withdraw my assertion that
> > > > > > we can’t have jars in svn. Those interested may want to
> > > > > > check out the thread at
> > > > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Greg.
> > > > > >
> > > > > > On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA)
> > > > > > <ji...@apache.org> wrote:
> > > > > >
> > > > > > >
> > > > > > > [
> > > > > > > https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > > > > > > ]
> > > > > > >
> > > > > > > Greg Trasuk updated RIVER-432:
> > > > > > > ------------------------------
> > > > > > >
> > > > > > > Attachment: river-2_2_remove_jars.diff
> > > > > > >
> > > > > > > The attached patch for the 2.2 branch does the following:
> > > > > > > - removes the 'asm' directory and 'tests/lib' directories
> > > > > > > which currently contain the asm library, mockito, and junit
> > > > > > > jars. - Modifies 'build.xml', 'common.xml', and adds
> > > > > > > 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at
> > > > > > > build time, and then used to retrieve the libraries
> > > > > > > mentioned above from Maven Central. This removes the need
> > > > > > > to have the jar files in svn. - Removes (as per discussion
> > > > > > > http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E)
> > > > > > > the VelocityConfigBuilder, and associated Velocity jars.
> > > > > > > Note that the 'extras' folder is not present in the 2.2
> > > > > > > branch, so Sim's last comments in the thread do not apply.
> > > > > > >
> > > > > > > > Jar files in svn and src distributions
> > > > > > > > --------------------------------------
> > > > > > > >
> > > > > > > > Key: RIVER-432
> > > > > > > > URL: https://issues.apache.org/jira/browse/RIVER-432
> > > > > > > > Project: River
> > > > > > > > Issue Type: Bug
> > > > > > > > Reporter: Greg Trasuk
> > > > > > > > Attachments: river-2_2_remove_jars.diff
> > > > > > > >
> > > > > > > >
> > > > > > > > Recent traffic on the incubator lists has pointed out that
> > > > > > > > including jar files for dependencies in the subversion
> > > > > > > > repository and the source distributions is against Apache
> > > > > > > > policy. In River, the following libraries appear in the
> > > > > > > > Subversion repository and the source distributions (these
> > > > > > > > are from trunk, a smaller set appear in the 2.2 branch):
> > > > > > > > animal-sniffer asm bouncy-castle dnsjava high-scale-lib
> > > > > > > > rc-libs
> > > > > > > > velocity
> > > > > > > > They all have to go. What are we using them for? As I
> > > > > > > > understand it, we were going to remove the
> > > > > > > > VelocityConfigurationBuilder, so that's not a problem.
> > > > > > > > Some of the others are available from Maven Central, so we
> > > > > > > > can get them at build time using Ivy or another build
> > > > > > > > tool. Which ones are actually required? And where did
> > > > > > > > they come from?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > This message was sent by Atlassian JIRA
> > > > > > > (v6.1.5#6160)
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> > > > > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag:
> > > > > 28088397
> > > >
> > >
> >
>
Build system and Java 8 was: Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Peter:
I’m not familiar with Java 8 yet. How is the current build not supported?
Cheers,
Greg.
On Feb 11, 2014, at 5:35 AM, Peter <ji...@zeus.net.au> wrote:
> +1 Peter.
>
> Note that the current build system does not support java 8.
>
> Maintaining a build system is a significant burden ( I know I had to implement Java 5 support).
>
> We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
>
> Regards,
>
> Peter.
> ----- Original message -----
>>
>> As discussion has settled somewhat, I would like to call another vote to
>> accept the latest patch described in
>> https://issues.apache.org/jira/browse/RIVER-432
>>
>> The patch removes the archived jar files for Velocity and ASM and
>> replaces them with Apache Ivy scripts that download the jars from Maven
>> Central the first time a build is done. From then on, the jar files are
>> in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
>>
>> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>>
>> Cheers,
>>
>> Greg.
>>
>>
>> On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>
>>>
>>> On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>>>
>>>> In order to gain some time to discuss this first i will vote -1.
>>>>
>>>> First, we decided to NOT remove velocity builder.
>>>
>>> When I read the email chain, my impression was that we wanted to
>>> remove it (to quote you Sim, “To be honest, I hate it”), but there was
>>> a dependency on it in the ‘extras’ folder that was added in the trunk
>>> branch. As there is no ‘extras’ in the 2.2 branch, and that is what
>>> this patch applies to, I thought it was fair to remove
>>> VelocityConfigurationBuilder from the 2.2 branch. Perhaps we should
>>> revisit the ConfigurationBuilder approach in another thread. For now
>>> I’ll spin another patch that doesn’t remove
>>> VelocityConfigurationBuilder.
>>>
>>>>
>>>> Second, no need to remove the jars as specified in your own comments
>>>> on RIVER-432.
>>>>
>>>> Pulling in external jars at compile time, shall we start here?
>>>>
>>>> They are already in the svn. They are already in the build scripts.
>>>> What does this patch fix? No legal problems?
>>>>
>>>
>>> Apache policy is somewhat unclear on this point. One needs to examine
>>> the mailing lists for clues on what we should really do. I will argue
>>> that:
>>>
>>> 1 - The fundamental distribution model of Apache is source code, not
>>> binaries. 2 - Distributing binaries is tolerated but not encouraged.
>>> Since the svn repository can be seen as a distribution point, binaries
>>> in svn are also tolerated but not encouraged. 3 - Downloading
>>> dependency binaries at build time is technologically easy, provides
>>> the same guarantees as putting them in cvs, and avoids the question of
>>> effectively distributing someone else’s code.
>>>
>>> All these together suggest that although we’re technically OK to put
>>> dependency jars in a “-deps” package (note that the status quo _is_
>>> unacceptable - at the very least, we need to restructure the
>>> dependencies into a “-deps” binary package), there is some policy
>>> uncertainty which we avoid totally by having dependencies downloaded
>>> from a known-good source at build time.
>>>
>>> Let’s examine these points:
>>>
>>> 1 - The fundamental distribution model of Apache is source code, not
>>> binaries. Apache began with httpd. Back in those days, “Open Source”
>>> software was distributed in source form only, simply because it was
>>> mostly intended for Unix systems (then later Linux). I recall the
>>> first release of Perl coming down as a ten-part uunet news message.
>>> Part of this distribution model was practical necessity - System
>>> differences made it necessary to compile your software on the hardware
>>> it was going to run on. Part of it was open-source philosophy.
>>> Having the source code meant that you could take a look at it and
>>> verify that it wasn’t hazardous to your operations.
>>>
>>> In any case, the way we use to use open source software was
>>> (“./configure; make; make install”). If the software had
>>> dependencies, you built them from source, for the same reasons.
>>>
>>> Now, as time has gone on, we’ve gotten used to having the JVM as a
>>> common runtime, and jar files as a common binary distribution medium.
>>> But the Apache Foundation’s mandate is to produce open source software
>>> that is freely usable under the Apache License. That means source
>>> code is at the heart of Apache, despite the rest of the world’s
>>> comfort with binaries. Hence Roy’s statements in (1):
>>>
>>>> Class files are not open source. Jar files filled with class files
>>>> are not open source. The fact that they are derived from open source
>>>> is applicable only to what we allow projects to be dependent upon,
>>>> not what we vote on as a release package. Release votes are on
>>>> verified open source artifacts. Binary packages are separate from
>>>> source packages. One cannot vote to approve a release containing a
>>>> mix of source and binary code because the binary is not open source
>>>> and cannot be verified to be safe for release (even if it was
>>>> derived from open source).
>>>>
>>>> I thought that was frigging obvious. Why do I need to write
>>>> documentation to explain something that is fundamental to the open
>>>> source definition?
>>> He’s talking about binary packages, not jar files in svn, but I read
>>> that (and many other emails) as a distaste for binary distributions.
>>>
>>> In fact, if you look at Apache httpd’s download page, it doesn’t
>>> appear that the Apache project publishes any Unix or Linux binaries.
>>> They leave that to other organizations.
>>>
>>> 2 - Distributing binaries is tolerated but not encouraged. Since the
>>> svn repository can be seen as a distribution point, binaries in svn
>>> are also tolerated but not encouraged.
>>>
>>> It’s hard to find a single reference that encapsulates this outlook,
>>> but that’s the impression I get from reading the various mailing
>>> lists. For instance, Sam Ruby says (2):
>>>> IMO, our projects release source. So, our projects should not
>>>> maintain object/binary artifacts in their svn release tree,
>>>> regardless of license (category a or b).
>>> There is some debate on whether the svn tree should be considered a
>>> distribution point. Incubator releases are regularly called out for
>>> not having “NOTICE” and “RELEASE” files at all reasonable checkout
>>> points in svn. [LEGAL-26]
>>> (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and
>>> remains unresolved.
>>>
>>> Doug Cutting (3) says:
>>>> On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
>>>> <st...@gmail.com> wrote:
>>>>> * Source control is not an Apache distribution and hence we do not
>>>>> need to have LICENSE and NOTICE files in source control, it can be
>>>>> a nice convenience, but there is no *requirement*.
>>>>
>>>> I think perhaps you're looking for clear lines where things are
>>>> actually a bit fuzzy. Certainly releases are official distributions
>>>> and need LICENSE and NOTICE files. That line is clear. On the other
>>>> hand, we try to discourage folks from thinking that source control is
>>>> a distribution. Rather we wish it to be considered our shared
>>>> workspace, containing works in progress, not yet always ready for
>>>> distribution to folks outside the foundation. But, since we work in
>>>> public, folks from outside the foundation can see our shared
>>>> workspace and might occasionally mistake it for an official
>>>> distribution. We'd like them to still see a LICENSE and NOTICE
>>>> file. So it's not a hard-and-fast requirement that every tree that
>>>> can possibly be checked out have a LICENSE and NOTICE file at its
>>>> root, but it's a good practice for those trees that are likely to be
>>>> checked out have them, so that folks who might consume them are well
>>>> informed.
>>> Again, he’s not talking directly about jar files in svn, however I
>>> think his statement that “since we work in public, folks from outside
>>> the foundation can see our shared workspace and might occasionally
>>> mistake it for an official distribution” applies here. Fundamentally,
>>> the decision on how and where to distribute ‘velocity.jar’ rightly
>>> belongs with the Velocity group and I don’t think we ought to
>>> redistribute it.
>>>
>>> 3 - Downloading dependency binaries at build time is technologically
>>> easy, provides the same guarantees as putting them in cvs, and avoids
>>> the question of effectively distributing someone else’s code.
>>>
>>> There doesn’t seem to be clear policy in the ASF on this, as evidenced
>>> by the frequent debates on it, and the lack of documentation. I’ve
>>> tried to lay out an argument that having jars in svn is not encouraged
>>> by the ASF (really, it’s not in line with the ASF’s charter), even if
>>> it isn’t disallowed. You may disagree, and I won’t claim I’ve made a
>>> strong argument, simply because the policy isn’t clear. So instead of
>>> going through arguments that amount to differences of opinion on
>>> Apache policy, let’s use a technological solution that is simple,
>>> common, and avoids the question altogether, by automatically
>>> downloading the dependencies at build time.
>>>
>>> Projects that use Maven do this automatic download as standard
>>> practice (that’s what Maven does, and that’s what the Maven Central
>>> infrastructure is there to support). We don’t use Maven, which is
>>> fine (our customers have asked us to make our binaries available in
>>> Maven Central, and we’ve done that). Apache Ivy is a popular add-on
>>> to Apache Ant that provides similar dependency resolution to an
>>> Ant-based build.
>>>
>>> I was a little surprised how easy it was to persuade Ivy to get the
>>> required dependencies at build time. The “ivy.xml” file is 39 lines
>>> including the ASL header (which by the way I forgot to include in the
>>> patch - I’ll fix that). There are about 50 lines added to ‘build.xml’
>>> to download Ivy and then download the required jar files
>>>
>>> So, given that the status-quo seems to be unacceptable (Roy talks
>>> about not having jar files in the open-source trees, only in “-deps”
>>> and “tools” trees), we have two options:
>>>
>>> (a) - restructure the svn repository and the build to allow a separate
>>> “-deps” distribution. This wouldn’t affect our binary distributions
>>> (note that I’m no longer using the term “binary release”), but to
>>> build from source, a user would have to download a separate archive,
>>> unpack it, and then copy those files into the directory that was
>>> unpacked from the source release. This option effectively still has
>>> us distributing dependent binaries, which is not the goal of the ASF,
>>> just with a disclaimer that says “this isn’t an ASF release, its just
>>> a binary distribution put together by a committer for your
>>> convenience, so don’t feel you should trust it too much”.
>>>
>>> (b) - use Ivy to get the jars from Maven Central automatically as part
>>> of the build.
>>>
>>> I think (b) is the option that causes the least hassle for our
>>> downstream consumers, and not much hassle for us.
>>>
>>>
>>>> Pulling external jars at compile time also makes it more difficult
>>>> to certify the software. In order to certify the software you need
>>>> to establish baseline that will be garanteed the same, even if you
>>>> pull it from the archive 10 years later.
>>>
>>> As I said above, Apache’s focus is creating software that can be built
>>> from source, not distributing binaries (note that QCG or another
>>> company might have a different focus, and is perfectly able to
>>> distribute binaries under the Apache license). I think a reasonably
>>> prudent user would ask “How can I trust the ‘velocity.jar’ that’s
>>> included in this binary?” And the answer would be either “because I
>>> built it from source and installed it in my corporate repository”
>>> (very cautious, but not unheard-of) or “It was published by the
>>> Velocity group to a trusted repository, Maven Central” (more common).
>>>
>>> If you look in the “ivy.xml” file you’ll see that the dependencies are
>>> specified using Maven-style “group-artifact-version” coordinates. Old
>>> versions are maintained in Maven Central forever. I suppose it’s
>>> possible that a publisher could convince Maven Central to remove a
>>> version for some reason (security or licensing problems perhaps), but
>>> then, would we want to be distributing that version in a “-deps”
>>> package?
>>>
>>> I agree that it’s not enough to just say “you need to download
>>> such-and-such jar”, hence the automatic download managed by “Ivy” from
>>> Maven Central.
>>>
>>>> It is not a high level project that builds on several frameworks. It
>>>> is a lowlevel system library. The stuff below the stack is minimal.
>>>> The number of jars we use is limited. Why bother?
>>>>
>>>
>>> In the currently released branches, the dependencies are limited to
>>> ASM and Velocity. Looking forward to the trunk branch and the
>>> qa_refactor branch, the number of external dependencies seem to be
>>> increasing (IMO I don’t like that, because I also view River as a low
>>> level system library, but I’m only one PMC member). We need to get in
>>> front of the problem before we start distributing large numbers of
>>> dependencies.
>>>
>>> This point rolls in with the general question of jar files in version
>>> control. I was always taught that version control was for source
>>> code, and putting binaries into version control was a bad idea. In
>>> addition, there are practical problems - with older systems like cvs,
>>> even doing an update or commit effectively downloads the binaries,
>>> which slows things down if there are large binary files. On newer
>>> distributed version control systems like git or Mercurial, the entire
>>> repository, including all versions of binary artifacts, comes down
>>> with the project checkout. Currently, we have one version of
>>> relatively few jar files in our repository, so it’s not a major issue.
>>> But it gets worse as time goes on. So I suggest we work out the
>>> technology now to avoid the problem.
>>>
>>>> Gr. Simon
>>>>
>>>
>>> Thanks for the questions, Sim. I hope you’ll come around to removing
>>> your ‘-1’.
>>>
>>> Cheers,
>>>
>>> Greg
>>>
>>> Footnotes
>>> ——————
>>>
>>> (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
>>> (2) - Sam Ruby - http://s.apache.org/r5
>>> (3) - Doug Cutting - http://s.apache.org/GNP
>>>
>>>> On 02-01-14 18:22, Greg Trasuk wrote:
>>>>>
>>>>> Hello all:
>>>>>
>>>>> Please have a look at the patch mentioned below and cast a vote on
>>>>> it.
>>>>>
>>>>> The main idea is to remove the dependency jar files from the
>>>>> source distribution. As a side effect of using Ivy, it becomes
>>>>> reasonable to remove them from the svn archive as well. Also, the
>>>>> Velocity dependency was there to support the
>>>>> VelocityConfigurationBuilder. We had discussed removing that
>>>>> component, so rather than move that dependency to Ivy, I’ve
>>>>> removed VelocityConfigurationBuilder.
>>>>>
>>>>> It’s arguable whether the VelocityConfigurationBuider was part of
>>>>> the official Jini API (I see it as a utility, not API), so I don’t
>>>>> think this commit actually requires a vote. However, it does seem
>>>>> like a significant change to the build process that ought to be
>>>>> reviewed. So I propose to treat this as a “lazy consensus” vote,
>>>>> and will commit the change to the 2.2 branch if there are no
>>>>> objections in 72 hours (i.e. 1730UTC 20140105).
>>>>>
>>>>> At the same time, based on discussions over on
>>>>> general@incubator.apache.org, I’ll withdraw my assertion that we
>>>>> can’t have jars in svn. Those interested may want to check out
>>>>> the thread at
>>>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg.
>>>>>
>>>>> On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA) <ji...@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>>>> ]
>>>>>>
>>>>>> Greg Trasuk updated RIVER-432:
>>>>>> ------------------------------
>>>>>>
>>>>>> Attachment: river-2_2_remove_jars.diff
>>>>>>
>>>>>> The attached patch for the 2.2 branch does the following:
>>>>>> - removes the 'asm' directory and 'tests/lib' directories which
>>>>>> currently contain the asm library, mockito, and junit jars. -
>>>>>> Modifies 'build.xml', 'common.xml', and adds 'ivy.xml' so that
>>>>>> the Apache Ivy ant plugin is downloaded at build time, and then
>>>>>> used to retrieve the libraries mentioned above from Maven
>>>>>> Central. This removes the need to have the jar files in svn. -
>>>>>> Removes (as per discussion
>>>>>> http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E)
>>>>>> the VelocityConfigBuilder, and associated Velocity jars. Note
>>>>>> that the 'extras' folder is not present in the 2.2 branch, so
>>>>>> Sim's last comments in the thread do not apply.
>>>>>>
>>>>>>> Jar files in svn and src distributions
>>>>>>> --------------------------------------
>>>>>>>
>>>>>>> Key: RIVER-432
>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-432
>>>>>>> Project: River
>>>>>>> Issue Type: Bug
>>>>>>> Reporter: Greg Trasuk
>>>>>>> Attachments: river-2_2_remove_jars.diff
>>>>>>>
>>>>>>>
>>>>>>> Recent traffic on the incubator lists has pointed out that
>>>>>>> including jar files for dependencies in the subversion
>>>>>>> repository and the source distributions is against Apache
>>>>>>> policy. In River, the following libraries appear in the
>>>>>>> Subversion repository and the source distributions (these are
>>>>>>> from trunk, a smaller set appear in the 2.2 branch):
>>>>>>> animal-sniffer asm bouncy-castle dnsjava high-scale-lib
>>>>>>> rc-libs
>>>>>>> velocity
>>>>>>> They all have to go. What are we using them for? As I
>>>>>>> understand it, we were going to remove the
>>>>>>> VelocityConfigurationBuilder, so that's not a problem. Some
>>>>>>> of the others are available from Maven Central, so we can get
>>>>>>> them at build time using Ivy or another build tool. Which
>>>>>>> ones are actually required? And where did they come from?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> This message was sent by Atlassian JIRA
>>>>>> (v6.1.5#6160)
>>>>>
>>>>
>>>>
>>>> --
>>>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>>>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>>
>>
>
Re: [Dicuss] Build Structure
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Feb 12, 2014, at 6:06 PM, Dennis Reedy <de...@gmail.com> wrote:
> Greg,
>
> Discussion ensues.
>
> A little tangent here that might be of interest. I worked on modularizing Blitz with Dawid Loubser, if you're interested in seeing how that ended up (pretty much follows the conventions being discussed), check it out herehttps://github.com/DawidLoubser/blitz-javaspaces-modularised
>
Looks nice.
> Regards
>
> Dennis
> <snip..>
>> not River’s build system. For application developers, the mechanism to build the artifacts that go into Central isn’t important.
>
> Building River services and deploying to central have nothing to do with each other.
>
What I mean is that most developers don’t need to build River. They need to build services that use River’s jar files (probably getting them out of Maven Central) and get deployed into an appropriate environment (or host their own env using river-starter). So we don’t need to get too hung up on making River’s build a thing of beauty.
<snip…>
>>
>> Also, does anyone remember the rationale as to what goes into jsk-lib as opposed to jsk-patform? Right now there’s some overlap between them.
>
> Whats the overlap?
I’ve added a report at the end of this email. Looks like most of the implementation is in jsk-platform, but some things don’t look consistent.
<snip…>
>
>>
>> Minor thing - could we keep it as “reggie-dl”, etc, rather than “reggie-proxy”? To me, *-dl expresses the intention a little better, since it’s all the classes that might need to be downloaded to the client, which might include other support in addition to the proxy. Either naming will work, but it would be good to be consistent.
>
> The proxy module calls out quite clearly what the module contains, and that one should never include a proxy module in one's classpath. However, if a service has an api module, that would become a classpath dependency for using a service, and have that service's proxy loaded dynamically (downloaded or loaded from the file system).
>
> To me I originally found the -dl.jar naming confusing. To the un-initiated, it is not obvious. Unless I know that dl means download, I have no idea what the dl is, encompasses or means. Using proxy seems quite clear.
>
OK. Like I said, minor point. I don’t have a strong opinion.
>> In building modules for a container, it’s kind of nice to be able to pickup on the name of the jar to indicate if it needs to go in the codebase annotation.
>
> And proxy fits the bill quite nicely IMO. My service's annotation is the proxy, and clients use the api as a classpath dependency.
>
The browser seems to like it if the ‘*-api.jar’ is in the codebase annotation as well.
>
>>
>>>
>>> river-start/
>>>
>>> river-tools/
>>> browser/
>>> classserver/
>>>
>>
>> I’d almost put class server into the starter framework. I don’t think it’s useful outside the service-starter.
>
> Meh. I use ServiceStarter, but not classerver. I use Rio's Webster. Some use Tomcat, some use Jetty. I wouldn't couple classerver with starter.
OK. river-container has its own class server implementation, anyway - it needed it to support codebase annotation per application.
<snip…>
>
>>>
>>> 1. In most cases an api module is not required for River core services since the API is defined is jsk-dl
>>>
>>
>> That’s probably open to argument. For example, is JavaSpace a “core” API? It always seemed to me like it landed inside Jini because it needed a home (I recall that at one time it was a separate project), but it seems more like an application API. I’m not saying it _should_ or _shouldn’t_ be split out, but it’s something to think about. Things like Registrar, however, seem to be pretty “core”.
>
> Well, it is net.jini.space.JavaSpace, are you advocating to move it out of the net.jini namespace?
No, that would be a nightmare for backwards-compatibility. You’re right, it’s in ‘net.jini’, so I suppose it’s presumptively “core”.
> Or, do you think that we should move all of the River service api's out of jsk-lib and put them specifically into an api module for each respective service?
Just thinking out loud, really. Right now I can’t think of any strong arguments for or against, so I’d say leave things as-is.
>
> However, Outrigger is a contributed implementation of JavaSpace(05), so it does not make sense to put it into the outrigger module?
Outrigger should definitely be in a different module. outrigger.jar and outrigger-dl.jar are totally optional in a given installation. They might be left out, or replaced with Blitz.
>
> Perhaps create a separate river-api module that includes all of net.jini service apis (Registrar, JavaSpace(05), TransactionManager,...). That might be a good idea.
>
I guess the question is whether you’d ever need the infrastructure service apis separately from the library classes in jsk-dl. Would you? Why might that be a good idea? (Again, I can’t think of any strong arguments - just thinking out loud. You said “that might be a good idea” - I’m wondering what the thought process was).
>>
>> Overall, a good start on the modules. We’ll need to settle on a tool (maven, Gradle, Ant, etc). I’m kind of with Simon on this - Maven is pretty standard, and I’d probably vote for it in the absence of strong arguments for a different build tool. Although I did notice as I was doing the container work that it sometimes does impose limits on the actual application (for example, I couldn’t for the life of me figure a clean way to get it to generate a module with a “.ssar” extension without writing a plugin, which I wasn’t at the time aware how to do, so I changed the deployment module to “.jar”).
>
> For me, Maven would be the quickest.
Same here.
>
>>
>> I’m assuming we’d wait to modularize until Peter declares ‘qa_refactor’ done, and merges it back into the trunk?
>
> Sure, or do the work in qa_refactor (up to Peter). I'd also recommend that as part of this we change the com.sun.jini namespace to org.apache.river, and make sure that for each module, we follow consistent package naming conventions:
>
> org.apache.river.<module-name>.api
> org.apache.river.<module-name>.proxy
> api: org.apache.river.<module-name>.impl
>
>
> Lastly, I'd alter my original work to change river-core to:
>
> river-core/
> river-dl/
> river-lib/
> river-platform/
> river-resources/
> river-policy
> river-serviceui/
I must confess that I feel an irrational attachment to the “jini” or “jsk” name. But I suppose I’d get over it.
Cheers,
Greg Trasuk
jsk-lib.jar vs jsk-platform.jar
=====================
282 classes in jsk-lib
754 classes in jsk-platform
There are 33 classes in both:
META-INF/
META-INF/MANIFEST.MF
META-INF/PREFERRED.LIST
com/
com/sun/
com/sun/jini/
com/sun/jini/action/
com/sun/jini/action/GetLongAction.class
com/sun/jini/config/
com/sun/jini/logging/
com/sun/jini/logging/Levels$ClassReplacingObjectOutputStream.class
com/sun/jini/logging/Levels$LevelData.class
com/sun/jini/logging/Levels.class
com/sun/jini/logging/LogUtil.class
com/sun/jini/resource/
com/sun/jini/resource/Service$1.class
com/sun/jini/resource/Service$LazyIterator.class
com/sun/jini/resource/Service.class
com/sun/jini/resource/ServiceConfigurationError.class
com/sun/jini/thread/
com/sun/jini/thread/Executor.class
com/sun/jini/thread/GetThreadPoolAction.class
com/sun/jini/thread/NewThreadAction$1.class
com/sun/jini/thread/NewThreadAction$2.class
com/sun/jini/thread/NewThreadAction.class
com/sun/jini/thread/ThreadPool$Task.class
com/sun/jini/thread/ThreadPool$Worker.class
com/sun/jini/thread/ThreadPool.class
com/sun/jini/thread/ThreadPoolPermission.class
net/
net/jini/
net/jini/discovery/
net/jini/discovery/Constants.class
There are 249 classes in jsk-lib but not jsk-platform:
com/sun/jini/admin/
com/sun/jini/admin/DestroyAdmin.class
com/sun/jini/admin/StorageLocationAdmin.class
com/sun/jini/config/Component.class
com/sun/jini/config/Config.class
com/sun/jini/constants/
com/sun/jini/constants/ThrowableConstants.class
com/sun/jini/constants/TimeConstants.class
com/sun/jini/landlord/
com/sun/jini/landlord/ConstrainableLandlordLease.class
com/sun/jini/landlord/ConstrainableLandlordLeaseMap.class
com/sun/jini/landlord/FixedLeasePeriodPolicy.class
com/sun/jini/landlord/Landlord$RenewResults.class
com/sun/jini/landlord/Landlord.class
com/sun/jini/landlord/LandlordLease.class
com/sun/jini/landlord/LandlordLeaseMap.class
com/sun/jini/landlord/LandlordProxyVerifier.class
com/sun/jini/landlord/LandlordUtil.class
com/sun/jini/landlord/LeaseFactory.class
com/sun/jini/landlord/LeasePeriodPolicy$Result.class
com/sun/jini/landlord/LeasePeriodPolicy.class
com/sun/jini/landlord/LeasedResource.class
com/sun/jini/landlord/LocalLandlord.class
com/sun/jini/lease/
com/sun/jini/lease/AbstractLease.class
com/sun/jini/lease/AbstractLeaseMap$Entry.class
com/sun/jini/lease/AbstractLeaseMap$EntryIterator.class
com/sun/jini/lease/AbstractLeaseMap$EntrySet.class
com/sun/jini/lease/AbstractLeaseMap.class
com/sun/jini/lease/BasicRenewalFailureEvent.class
com/sun/jini/lookup/
com/sun/jini/lookup/entry/
com/sun/jini/lookup/entry/BasicServiceType.class
com/sun/jini/lookup/entry/LookupAttributes$FieldComparator.class
com/sun/jini/lookup/entry/LookupAttributes.class
com/sun/jini/phoenix/
com/sun/jini/phoenix/ActivationAdmin.class
com/sun/jini/proxy/
com/sun/jini/proxy/BasicProxyTrustVerifier.class
com/sun/jini/proxy/ConstrainableProxyUtil.class
com/sun/jini/proxy/MarshalledWrapper.class
com/sun/jini/proxy/ThrowThis.class
com/sun/jini/reliableLog/
com/sun/jini/reliableLog/LogException.class
com/sun/jini/reliableLog/LogHandler.class
com/sun/jini/reliableLog/LogInputStream.class
com/sun/jini/reliableLog/LogOutputStream.class
com/sun/jini/reliableLog/ReliableLog.class
com/sun/jini/start/
com/sun/jini/start/LifeCycle.class
com/sun/jini/start/ServiceProxyAccessor.class
com/sun/jini/thread/InProgress.class
com/sun/jini/thread/InterruptedStatusThread.class
com/sun/jini/thread/ReadersWriter$ConcurrentLockException.class
com/sun/jini/thread/ReadersWriter.class
com/sun/jini/thread/ReadyState$RemoteExceptionWrapper.class
com/sun/jini/thread/ReadyState.class
com/sun/jini/thread/RetryTask$1.class
com/sun/jini/thread/RetryTask$RetryTime.class
com/sun/jini/thread/RetryTask.class
com/sun/jini/thread/StreamPlugThread.class
com/sun/jini/thread/TaskManager$Task.class
com/sun/jini/thread/TaskManager$TaskThread.class
com/sun/jini/thread/TaskManager.class
com/sun/jini/thread/WakeupManager$1.class
com/sun/jini/thread/WakeupManager$Kicker.class
com/sun/jini/thread/WakeupManager$ThreadDesc.class
com/sun/jini/thread/WakeupManager$Ticket.class
com/sun/jini/thread/WakeupManager.class
net/jini/admin/
net/jini/admin/Administrable.class
net/jini/admin/JoinAdmin.class
net/jini/discovery/DiscoveryChangeListener.class
net/jini/discovery/DiscoveryEvent.class
net/jini/discovery/DiscoveryGroupManagement.class
net/jini/discovery/DiscoveryListener.class
net/jini/discovery/DiscoveryLocatorManagement.class
net/jini/discovery/DiscoveryManagement.class
net/jini/discovery/DiscoveryPermission$1.class
net/jini/discovery/DiscoveryPermission$Collection.class
net/jini/discovery/DiscoveryPermission.class
net/jini/discovery/IncomingMulticastAnnouncement.class
net/jini/discovery/IncomingMulticastRequest.class
net/jini/discovery/IncomingUnicastRequest.class
net/jini/discovery/IncomingUnicastResponse.class
net/jini/discovery/LookupDiscovery$1.class
net/jini/discovery/LookupDiscovery$10.class
net/jini/discovery/LookupDiscovery$11.class
net/jini/discovery/LookupDiscovery$12$1.class
net/jini/discovery/LookupDiscovery$12.class
net/jini/discovery/LookupDiscovery$13.class
net/jini/discovery/LookupDiscovery$2.class
net/jini/discovery/LookupDiscovery$3.class
net/jini/discovery/LookupDiscovery$4.class
net/jini/discovery/LookupDiscovery$5.class
net/jini/discovery/LookupDiscovery$6.class
net/jini/discovery/LookupDiscovery$7.class
net/jini/discovery/LookupDiscovery$8.class
net/jini/discovery/LookupDiscovery$9.class
net/jini/discovery/LookupDiscovery$AnnouncementInfo.class
net/jini/discovery/LookupDiscovery$AnnouncementListener.class
net/jini/discovery/LookupDiscovery$AnnouncementTimerThread.class
net/jini/discovery/LookupDiscovery$CheckGroupsMarker.class
net/jini/discovery/LookupDiscovery$CheckReachabilityMarker.class
net/jini/discovery/LookupDiscovery$DecodeAnnouncementTask$1.class
net/jini/discovery/LookupDiscovery$DecodeAnnouncementTask.class
net/jini/discovery/LookupDiscovery$Notifier$1.class
net/jini/discovery/LookupDiscovery$Notifier.class
net/jini/discovery/LookupDiscovery$NotifyTask.class
net/jini/discovery/LookupDiscovery$Requestor.class
net/jini/discovery/LookupDiscovery$ResponseListener.class
net/jini/discovery/LookupDiscovery$UnicastDiscoveryTask$1.class
net/jini/discovery/LookupDiscovery$UnicastDiscoveryTask$2.class
net/jini/discovery/LookupDiscovery$UnicastDiscoveryTask.class
net/jini/discovery/LookupDiscovery.class
net/jini/discovery/LookupDiscoveryManager$1.class
net/jini/discovery/LookupDiscoveryManager$GroupDiscoveryListener.class
net/jini/discovery/LookupDiscoveryManager$LocatorDiscoveryListener.class
net/jini/discovery/LookupDiscoveryManager$ProxyReg.class
net/jini/discovery/LookupDiscoveryManager.class
net/jini/discovery/LookupDiscoveryRegistration.class
net/jini/discovery/LookupDiscoveryService.class
net/jini/discovery/LookupLocatorDiscovery$1.class
net/jini/discovery/LookupLocatorDiscovery$DiscoveryTask.class
net/jini/discovery/LookupLocatorDiscovery$LocatorReg$1.class
net/jini/discovery/LookupLocatorDiscovery$LocatorReg$2.class
net/jini/discovery/LookupLocatorDiscovery$LocatorReg.class
net/jini/discovery/LookupLocatorDiscovery$Notifier.class
net/jini/discovery/LookupLocatorDiscovery$NotifyTask.class
net/jini/discovery/LookupLocatorDiscovery.class
net/jini/discovery/LookupUnmarshalException.class
net/jini/discovery/OutgoingMulticastAnnouncement$1.class
net/jini/discovery/OutgoingMulticastAnnouncement.class
net/jini/discovery/OutgoingMulticastRequest.class
net/jini/discovery/OutgoingUnicastRequest.class
net/jini/discovery/OutgoingUnicastResponse.class
net/jini/discovery/RemoteDiscoveryEvent.class
net/jini/entry/
net/jini/entry/AbstractEntry.class
net/jini/entry/UnusableEntriesException.class
net/jini/event/
net/jini/event/EventMailbox.class
net/jini/event/InvalidIteratorException.class
net/jini/event/MailboxPullRegistration.class
net/jini/event/MailboxRegistration.class
net/jini/event/PullEventMailbox.class
net/jini/event/RemoteEventIterator.class
net/jini/lease/
net/jini/lease/DesiredExpirationListener.class
net/jini/lease/ExpirationWarningEvent.class
net/jini/lease/LeaseListener.class
net/jini/lease/LeaseRenewalEvent.class
net/jini/lease/LeaseRenewalManager$Entry.class
net/jini/lease/LeaseRenewalManager$QueuerTask.class
net/jini/lease/LeaseRenewalManager$RenewTask.class
net/jini/lease/LeaseRenewalManager.class
net/jini/lease/LeaseRenewalService.class
net/jini/lease/LeaseRenewalSet.class
net/jini/lease/LeaseUnmarshalException.class
net/jini/lease/RenewalFailureEvent.class
net/jini/lookup/
net/jini/lookup/DiscoveryAdmin.class
net/jini/lookup/JoinManager$1.class
net/jini/lookup/JoinManager$AddAttributesTask.class
net/jini/lookup/JoinManager$DiscMgrListener.class
net/jini/lookup/JoinManager$DiscardProxyTask.class
net/jini/lookup/JoinManager$JoinTask.class
net/jini/lookup/JoinManager$LeaseExpireNotifyTask.class
net/jini/lookup/JoinManager$ModifyAttributesTask.class
net/jini/lookup/JoinManager$ProxyReg$DiscLeaseListener.class
net/jini/lookup/JoinManager$ProxyReg.class
net/jini/lookup/JoinManager$ProxyRegTask.class
net/jini/lookup/JoinManager$RegisterTask.class
net/jini/lookup/JoinManager$SetAttributesTask.class
net/jini/lookup/JoinManager.class
net/jini/lookup/LookupCache.class
net/jini/lookup/ServiceDiscoveryEvent.class
net/jini/lookup/ServiceDiscoveryListener.class
net/jini/lookup/ServiceDiscoveryManager$1.class
net/jini/lookup/ServiceDiscoveryManager$CacheTask.class
net/jini/lookup/ServiceDiscoveryManager$DiscMgrListener.class
net/jini/lookup/ServiceDiscoveryManager$EventReg.class
net/jini/lookup/ServiceDiscoveryManager$LeaseListenerImpl.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$DiscardServiceTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$LookupListener.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$LookupListener_Stub.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$LookupTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$NewOldServiceTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$NotifyEventTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$ProxyRegDropTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$RegisterListenerTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$ServiceDiscardTimerTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl$UnmapProxyTask.class
net/jini/lookup/ServiceDiscoveryManager$LookupCacheImpl.class
net/jini/lookup/ServiceDiscoveryManager$ProxyReg.class
net/jini/lookup/ServiceDiscoveryManager$ServiceDiscoveryListenerImpl.class
net/jini/lookup/ServiceDiscoveryManager$ServiceIdTask.class
net/jini/lookup/ServiceDiscoveryManager$ServiceItemReg.class
net/jini/lookup/ServiceDiscoveryManager.class
net/jini/lookup/ServiceIDListener.class
net/jini/lookup/ServiceItemFilter.class
net/jini/lookup/entry/
net/jini/lookup/entry/Address.class
net/jini/lookup/entry/AddressBean.class
net/jini/lookup/entry/Comment.class
net/jini/lookup/entry/CommentBean.class
net/jini/lookup/entry/EntryBean.class
net/jini/lookup/entry/EntryBeans.class
net/jini/lookup/entry/Host.class
net/jini/lookup/entry/Location.class
net/jini/lookup/entry/LocationBean.class
net/jini/lookup/entry/Name.class
net/jini/lookup/entry/NameBean.class
net/jini/lookup/entry/ServiceControlled.class
net/jini/lookup/entry/ServiceInfo.class
net/jini/lookup/entry/ServiceInfoBean.class
net/jini/lookup/entry/ServiceType.class
net/jini/lookup/entry/Status.class
net/jini/lookup/entry/StatusBean.class
net/jini/lookup/entry/StatusType.class
net/jini/lookup/entry/UIDescriptor.class
net/jini/lookup/entry/UIDescriptorBean.class
net/jini/lookup/entry/jmx/
net/jini/lookup/entry/jmx/JMXProperty.class
net/jini/lookup/entry/jmx/JMXProtocolType.class
net/jini/lookup/ui/
net/jini/lookup/ui/AboutUI.class
net/jini/lookup/ui/AdminUI.class
net/jini/lookup/ui/MainUI.class
net/jini/lookup/ui/attribute/
net/jini/lookup/ui/attribute/AccessibleUI.class
net/jini/lookup/ui/attribute/Locales.class
net/jini/lookup/ui/attribute/RequiredPackages.class
net/jini/lookup/ui/attribute/UIFactoryTypes.class
net/jini/lookup/ui/factory/
net/jini/lookup/ui/factory/DialogFactory.class
net/jini/lookup/ui/factory/FrameFactory.class
net/jini/lookup/ui/factory/JComponentFactory.class
net/jini/lookup/ui/factory/JDialogFactory.class
net/jini/lookup/ui/factory/JFrameFactory.class
net/jini/lookup/ui/factory/JWindowFactory.class
net/jini/lookup/ui/factory/PanelFactory.class
net/jini/lookup/ui/factory/WindowFactory.class
net/jini/space/
net/jini/space/AvailabilityEvent.class
net/jini/space/InternalSpaceException.class
net/jini/space/JavaSpace.class
net/jini/space/JavaSpace05.class
net/jini/space/MatchSet.class
There are 721 classes in jsk-platform but not jsk-lib:
com/sun/jini/action/GetBooleanAction.class
com/sun/jini/action/GetIntegerAction.class
com/sun/jini/action/GetPropertyAction.class
com/sun/jini/collection/
com/sun/jini/collection/SoftCache$Value.class
com/sun/jini/collection/SoftCache.class
com/sun/jini/collection/WeakIdentityMap$Key.class
com/sun/jini/collection/WeakIdentityMap.class
com/sun/jini/collection/WeakSoftTable$RemovableReference.class
com/sun/jini/collection/WeakSoftTable$SoftValue.class
com/sun/jini/collection/WeakSoftTable$WeakKey.class
com/sun/jini/collection/WeakSoftTable.class
com/sun/jini/config/ConfigUtil.class
com/sun/jini/config/KeyStores.class
com/sun/jini/discovery/
com/sun/jini/discovery/ClientPermissionChecker.class
com/sun/jini/discovery/ClientSubjectChecker.class
com/sun/jini/discovery/DatagramBufferFactory.class
com/sun/jini/discovery/DelayedMulticastAnnouncementDecoder.class
com/sun/jini/discovery/DelayedMulticastRequestDecoder.class
com/sun/jini/discovery/Discovery.class
com/sun/jini/discovery/DiscoveryConstraintTrustVerifier.class
com/sun/jini/discovery/DiscoveryConstraints$ConnectionAbsoluteTimeReducer.class
com/sun/jini/discovery/DiscoveryConstraints$ConstraintReducer.class
com/sun/jini/discovery/DiscoveryConstraints$MaxValueReducer.class
com/sun/jini/discovery/DiscoveryConstraints$MulticastMaxPacketSizeReducer.class
com/sun/jini/discovery/DiscoveryConstraints.class
com/sun/jini/discovery/DiscoveryFormatProvider.class
com/sun/jini/discovery/DiscoveryProtocolException.class
com/sun/jini/discovery/DiscoveryProtocolVersion.class
com/sun/jini/discovery/DiscoveryV1$1.class
com/sun/jini/discovery/DiscoveryV1$2.class
com/sun/jini/discovery/DiscoveryV1.class
com/sun/jini/discovery/DiscoveryV2$1.class
com/sun/jini/discovery/DiscoveryV2$2.class
com/sun/jini/discovery/DiscoveryV2$3.class
com/sun/jini/discovery/DiscoveryV2$4.class
com/sun/jini/discovery/DiscoveryV2$DatagramBuffers$DatagramInfo.class
com/sun/jini/discovery/DiscoveryV2$DatagramBuffers.class
com/sun/jini/discovery/DiscoveryV2.class
com/sun/jini/discovery/EncodeIterator.class
com/sun/jini/discovery/MulticastAnnouncement.class
com/sun/jini/discovery/MulticastAnnouncementDecoder.class
com/sun/jini/discovery/MulticastAnnouncementEncoder.class
com/sun/jini/discovery/MulticastMaxPacketSize.class
com/sun/jini/discovery/MulticastRequest.class
com/sun/jini/discovery/MulticastRequestDecoder.class
com/sun/jini/discovery/MulticastRequestEncoder.class
com/sun/jini/discovery/MulticastTimeToLive.class
com/sun/jini/discovery/UnicastDiscoveryClient.class
com/sun/jini/discovery/UnicastDiscoveryServer.class
com/sun/jini/discovery/UnicastResponse.class
com/sun/jini/discovery/UnicastSocketTimeout.class
com/sun/jini/discovery/internal/
com/sun/jini/discovery/internal/BaseProvider.class
com/sun/jini/discovery/internal/EndpointBasedClient$ConnManagerFactoryImpl$1$1.class
com/sun/jini/discovery/internal/EndpointBasedClient$ConnManagerFactoryImpl$1.class
com/sun/jini/discovery/internal/EndpointBasedClient$ConnManagerFactoryImpl.class
com/sun/jini/discovery/internal/EndpointBasedClient$ConnectionInfo.class
com/sun/jini/discovery/internal/EndpointBasedClient$PrearrangedSocketFactory.class
com/sun/jini/discovery/internal/EndpointBasedClient.class
com/sun/jini/discovery/internal/EndpointBasedProvider.class
com/sun/jini/discovery/internal/EndpointBasedServer$1.class
com/sun/jini/discovery/internal/EndpointBasedServer$ListenContextImpl$1.class
com/sun/jini/discovery/internal/EndpointBasedServer$ListenContextImpl.class
com/sun/jini/discovery/internal/EndpointBasedServer$PrearrangedServerSocket.class
com/sun/jini/discovery/internal/EndpointBasedServer$PrearrangedServerSocketFactory.class
com/sun/jini/discovery/internal/EndpointBasedServer$ServerConnManagerImpl.class
com/sun/jini/discovery/internal/EndpointBasedServer.class
com/sun/jini/discovery/internal/EndpointInternals.class
com/sun/jini/discovery/internal/EndpointInternalsPermission.class
com/sun/jini/discovery/internal/KerberosEndpointInternalsAccess.class
com/sun/jini/discovery/internal/MultiIPDiscovery.class
com/sun/jini/discovery/internal/Plaintext.class
com/sun/jini/discovery/internal/SslEndpointInternalsAccess.class
com/sun/jini/discovery/internal/X500Client$1.class
com/sun/jini/discovery/internal/X500Client$X500MulticastAnnouncement.class
com/sun/jini/discovery/internal/X500Client.class
com/sun/jini/discovery/internal/X500Constraints.class
com/sun/jini/discovery/internal/X500Provider$1.class
com/sun/jini/discovery/internal/X500Provider$2.class
com/sun/jini/discovery/internal/X500Provider$SigningBufferFactory$BufferInfo.class
com/sun/jini/discovery/internal/X500Provider$SigningBufferFactory.class
com/sun/jini/discovery/internal/X500Provider.class
com/sun/jini/discovery/internal/X500Server$1.class
com/sun/jini/discovery/internal/X500Server$X500MulticastRequest.class
com/sun/jini/discovery/internal/X500Server.class
com/sun/jini/discovery/kerberos/
com/sun/jini/discovery/kerberos/Client$ClientImpl$1.class
com/sun/jini/discovery/kerberos/Client$ClientImpl.class
com/sun/jini/discovery/kerberos/Client.class
com/sun/jini/discovery/kerberos/Server$ServerImpl$1.class
com/sun/jini/discovery/kerberos/Server$ServerImpl.class
com/sun/jini/discovery/kerberos/Server.class
com/sun/jini/discovery/plaintext/
com/sun/jini/discovery/plaintext/Client.class
com/sun/jini/discovery/plaintext/Server.class
com/sun/jini/discovery/ssl/
com/sun/jini/discovery/ssl/Client$ClientImpl$1.class
com/sun/jini/discovery/ssl/Client$ClientImpl.class
com/sun/jini/discovery/ssl/Client.class
com/sun/jini/discovery/ssl/Server$ServerImpl$1.class
com/sun/jini/discovery/ssl/Server$ServerImpl.class
com/sun/jini/discovery/ssl/Server.class
com/sun/jini/discovery/x500/
com/sun/jini/discovery/x500/sha1withdsa/
com/sun/jini/discovery/x500/sha1withdsa/Client$ClientImpl.class
com/sun/jini/discovery/x500/sha1withdsa/Client.class
com/sun/jini/discovery/x500/sha1withdsa/Constants.class
com/sun/jini/discovery/x500/sha1withdsa/Server$ServerImpl.class
com/sun/jini/discovery/x500/sha1withdsa/Server.class
com/sun/jini/discovery/x500/sha1withrsa/
com/sun/jini/discovery/x500/sha1withrsa/Client$ClientImpl.class
com/sun/jini/discovery/x500/sha1withrsa/Client.class
com/sun/jini/discovery/x500/sha1withrsa/Constants.class
com/sun/jini/discovery/x500/sha1withrsa/Server$ServerImpl.class
com/sun/jini/discovery/x500/sha1withrsa/Server.class
com/sun/jini/jeri/
com/sun/jini/jeri/internal/
com/sun/jini/jeri/internal/connection/
com/sun/jini/jeri/internal/connection/BasicConnManagerFactory$1.class
com/sun/jini/jeri/internal/connection/BasicConnManagerFactory.class
com/sun/jini/jeri/internal/connection/BasicServerConnManager.class
com/sun/jini/jeri/internal/connection/ConnManager.class
com/sun/jini/jeri/internal/connection/ConnManagerFactory.class
com/sun/jini/jeri/internal/connection/ServerConnManager.class
com/sun/jini/jeri/internal/http/
com/sun/jini/jeri/internal/http/ConnectionTimer$TimeoutMap.class
com/sun/jini/jeri/internal/http/ConnectionTimer.class
com/sun/jini/jeri/internal/http/Header$FieldKey.class
com/sun/jini/jeri/internal/http/Header.class
com/sun/jini/jeri/internal/http/HttpClientConnection$1.class
com/sun/jini/jeri/internal/http/HttpClientConnection$OutboundRequestImpl.class
com/sun/jini/jeri/internal/http/HttpClientConnection.class
com/sun/jini/jeri/internal/http/HttpClientManager$ServerKey.class
com/sun/jini/jeri/internal/http/HttpClientManager.class
com/sun/jini/jeri/internal/http/HttpClientSocketFactory.class
com/sun/jini/jeri/internal/http/HttpParseException.class
com/sun/jini/jeri/internal/http/HttpServerConnection$1.class
com/sun/jini/jeri/internal/http/HttpServerConnection$Dispatcher.class
com/sun/jini/jeri/internal/http/HttpServerConnection$InboundRequestImpl$1.class
com/sun/jini/jeri/internal/http/HttpServerConnection$InboundRequestImpl.class
com/sun/jini/jeri/internal/http/HttpServerConnection.class
com/sun/jini/jeri/internal/http/HttpServerManager$1.class
com/sun/jini/jeri/internal/http/HttpServerManager$AckListenerMap.class
com/sun/jini/jeri/internal/http/HttpServerManager.class
com/sun/jini/jeri/internal/http/HttpSettings.class
com/sun/jini/jeri/internal/http/MessageReader$BoundedInputStream.class
com/sun/jini/jeri/internal/http/MessageReader$ChunkedInputStream.class
com/sun/jini/jeri/internal/http/MessageReader.class
com/sun/jini/jeri/internal/http/MessageWriter$ChunkedOutputStream.class
com/sun/jini/jeri/internal/http/MessageWriter.class
com/sun/jini/jeri/internal/http/Request$1.class
com/sun/jini/jeri/internal/http/Request$ContentInputStream.class
com/sun/jini/jeri/internal/http/Request$ContentOutputStream.class
com/sun/jini/jeri/internal/http/Request.class
com/sun/jini/jeri/internal/http/ServerInfo$1.class
com/sun/jini/jeri/internal/http/ServerInfo$LineParser.class
com/sun/jini/jeri/internal/http/ServerInfo.class
com/sun/jini/jeri/internal/http/StartLine.class
com/sun/jini/jeri/internal/http/TimedConnection.class
com/sun/jini/jeri/internal/http/TimedMap$1.class
com/sun/jini/jeri/internal/http/TimedMap$Evictor.class
com/sun/jini/jeri/internal/http/TimedMap$Mapping.class
com/sun/jini/jeri/internal/http/TimedMap$Queue$Node.class
com/sun/jini/jeri/internal/http/TimedMap$Queue.class
com/sun/jini/jeri/internal/http/TimedMap.class
com/sun/jini/jeri/internal/mux/
com/sun/jini/jeri/internal/mux/ConnectionIO.class
com/sun/jini/jeri/internal/mux/IOFuture.class
com/sun/jini/jeri/internal/mux/Mux$1.class
com/sun/jini/jeri/internal/mux/Mux$SessionShutdownTask.class
com/sun/jini/jeri/internal/mux/Mux.class
com/sun/jini/jeri/internal/mux/MuxClient.class
com/sun/jini/jeri/internal/mux/MuxServer$1$1.class
com/sun/jini/jeri/internal/mux/MuxServer$1.class
com/sun/jini/jeri/internal/mux/MuxServer.class
com/sun/jini/jeri/internal/mux/ProtocolException.class
com/sun/jini/jeri/internal/mux/Session$1.class
com/sun/jini/jeri/internal/mux/Session$2$1.class
com/sun/jini/jeri/internal/mux/Session$2.class
com/sun/jini/jeri/internal/mux/Session$3.class
com/sun/jini/jeri/internal/mux/Session$MuxInputStream.class
com/sun/jini/jeri/internal/mux/Session$MuxOutputStream.class
com/sun/jini/jeri/internal/mux/Session.class
com/sun/jini/jeri/internal/mux/SocketChannelConnectionIO$1.class
com/sun/jini/jeri/internal/mux/SocketChannelConnectionIO$Handler.class
com/sun/jini/jeri/internal/mux/SocketChannelConnectionIO.class
com/sun/jini/jeri/internal/mux/StreamConnectionIO$1.class
com/sun/jini/jeri/internal/mux/StreamConnectionIO$2.class
com/sun/jini/jeri/internal/mux/StreamConnectionIO$Reader.class
com/sun/jini/jeri/internal/mux/StreamConnectionIO$Writer.class
com/sun/jini/jeri/internal/mux/StreamConnectionIO.class
com/sun/jini/jeri/internal/runtime/
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$1.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$CleanRequest.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$DgcProxy.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$EndpointEntry$1.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$EndpointEntry$RefEntry$PhantomLiveRef.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$EndpointEntry$RefEntry.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$EndpointEntry$RenewCleanThread.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient$EndpointEntry.class
com/sun/jini/jeri/internal/runtime/AbstractDgcClient.class
com/sun/jini/jeri/internal/runtime/BASE64Encoder.class
com/sun/jini/jeri/internal/runtime/BasicExportTable$Entry.class
com/sun/jini/jeri/internal/runtime/BasicExportTable$LC.class
com/sun/jini/jeri/internal/runtime/BasicExportTable.class
com/sun/jini/jeri/internal/runtime/Binding$1.class
com/sun/jini/jeri/internal/runtime/Binding$2.class
com/sun/jini/jeri/internal/runtime/Binding.class
com/sun/jini/jeri/internal/runtime/CharacterEncoder.class
com/sun/jini/jeri/internal/runtime/DgcClient$DgcProxyImpl$1.class
com/sun/jini/jeri/internal/runtime/DgcClient$DgcProxyImpl$2.class
com/sun/jini/jeri/internal/runtime/DgcClient$DgcProxyImpl.class
com/sun/jini/jeri/internal/runtime/DgcClient.class
com/sun/jini/jeri/internal/runtime/DgcRequestDispatcher$1.class
com/sun/jini/jeri/internal/runtime/DgcRequestDispatcher$2.class
com/sun/jini/jeri/internal/runtime/DgcRequestDispatcher$3.class
com/sun/jini/jeri/internal/runtime/DgcRequestDispatcher$4.class
com/sun/jini/jeri/internal/runtime/DgcRequestDispatcher.class
com/sun/jini/jeri/internal/runtime/DgcServer.class
com/sun/jini/jeri/internal/runtime/HexDumpEncoder.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$1.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$ImplRef$1$1.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$ImplRef$1.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$ImplRef$2.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$ImplRef$3.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$ImplRef.class
com/sun/jini/jeri/internal/runtime/ImplRefManager$Reaper.class
com/sun/jini/jeri/internal/runtime/ImplRefManager.class
com/sun/jini/jeri/internal/runtime/Jeri.class
com/sun/jini/jeri/internal/runtime/JvmLifeSupport$1.class
com/sun/jini/jeri/internal/runtime/JvmLifeSupport$2.class
com/sun/jini/jeri/internal/runtime/JvmLifeSupport.class
com/sun/jini/jeri/internal/runtime/Lease.class
com/sun/jini/jeri/internal/runtime/ObjectTable$1.class
com/sun/jini/jeri/internal/runtime/ObjectTable$DgcServerImpl.class
com/sun/jini/jeri/internal/runtime/ObjectTable$LeaseChecker.class
com/sun/jini/jeri/internal/runtime/ObjectTable$NoSuchObject.class
com/sun/jini/jeri/internal/runtime/ObjectTable.class
com/sun/jini/jeri/internal/runtime/SameClassKey.class
com/sun/jini/jeri/internal/runtime/SelectionManager$1.class
com/sun/jini/jeri/internal/runtime/SelectionManager$Key.class
com/sun/jini/jeri/internal/runtime/SelectionManager$SelectLoop.class
com/sun/jini/jeri/internal/runtime/SelectionManager$SelectionHandler.class
com/sun/jini/jeri/internal/runtime/SelectionManager.class
com/sun/jini/jeri/internal/runtime/SequenceEntry.class
com/sun/jini/jeri/internal/runtime/Target$1.class
com/sun/jini/jeri/internal/runtime/Target$2.class
com/sun/jini/jeri/internal/runtime/Target.class
com/sun/jini/jeri/internal/runtime/Util$ClientHostImpl.class
com/sun/jini/jeri/internal/runtime/Util$ClientSubjectImpl.class
com/sun/jini/jeri/internal/runtime/Util$IntegrityEnforcementImpl.class
com/sun/jini/jeri/internal/runtime/Util$LazyMethodToHash_Map.class
com/sun/jini/jeri/internal/runtime/Util$TableCache.class
com/sun/jini/jeri/internal/runtime/Util.class
com/sun/jini/jeri/internal/runtime/WeakKey.class
com/sun/jini/loader/
com/sun/jini/loader/pref/
com/sun/jini/loader/pref/internal/
com/sun/jini/loader/pref/internal/PreferredResources.class
com/sun/jini/logging/LogManager$Probe.class
com/sun/jini/logging/LogManager.class
net/jini/activation/
net/jini/activation/ActivatableInvocationHandler$1.class
net/jini/activation/ActivatableInvocationHandler$2.class
net/jini/activation/ActivatableInvocationHandler$Failure.class
net/jini/activation/ActivatableInvocationHandler.class
net/jini/activation/ActivationExporter.class
net/jini/activation/ActivationGroup$1.class
net/jini/activation/ActivationGroup.class
net/jini/config/
net/jini/config/AbstractConfiguration$Primitive.class
net/jini/config/AbstractConfiguration.class
net/jini/config/Configuration$1.class
net/jini/config/Configuration$2.class
net/jini/config/Configuration.class
net/jini/config/ConfigurationException.class
net/jini/config/ConfigurationFile$1.class
net/jini/config/ConfigurationFile$ArrayConstructor.class
net/jini/config/ConfigurationFile$Call.class
net/jini/config/ConfigurationFile$Cast.class
net/jini/config/ConfigurationFile$ClassLiteral.class
net/jini/config/ConfigurationFile$ConstructorCall.class
net/jini/config/ConfigurationFile$Entry.class
net/jini/config/ConfigurationFile$ErrorDescriptor.class
net/jini/config/ConfigurationFile$Literal.class
net/jini/config/ConfigurationFile$MethodCall.class
net/jini/config/ConfigurationFile$NameRef.class
net/jini/config/ConfigurationFile$ParseNode.class
net/jini/config/ConfigurationFile$Parser.class
net/jini/config/ConfigurationFile$PushbackStreamTokenizer.class
net/jini/config/ConfigurationFile$StringConcatenation.class
net/jini/config/ConfigurationFile$StringLiteral.class
net/jini/config/ConfigurationFile$ThisRef.class
net/jini/config/ConfigurationFile.class
net/jini/config/ConfigurationNotFoundException.class
net/jini/config/ConfigurationProvider$1.class
net/jini/config/ConfigurationProvider$2.class
net/jini/config/ConfigurationProvider.class
net/jini/config/EmptyConfiguration.class
net/jini/config/NoSuchEntryException.class
net/jini/config/UnicodeEscapesDecodingReader.class
net/jini/config/Utilities.class
net/jini/constraint/
net/jini/constraint/BasicMethodConstraints$1.class
net/jini/constraint/BasicMethodConstraints$MethodDesc.class
net/jini/constraint/BasicMethodConstraints.class
net/jini/constraint/ConstraintTrustVerifier.class
net/jini/core/
net/jini/core/constraint/
net/jini/core/constraint/ArraySet$Iter.class
net/jini/core/constraint/ArraySet.class
net/jini/core/constraint/ClientAuthentication.class
net/jini/core/constraint/ClientMaxPrincipal.class
net/jini/core/constraint/ClientMaxPrincipalType.class
net/jini/core/constraint/ClientMinPrincipal.class
net/jini/core/constraint/ClientMinPrincipalType.class
net/jini/core/constraint/Confidentiality.class
net/jini/core/constraint/ConnectionAbsoluteTime.class
net/jini/core/constraint/ConnectionRelativeTime.class
net/jini/core/constraint/Constraint.class
net/jini/core/constraint/ConstraintAlternatives.class
net/jini/core/constraint/Delegation.class
net/jini/core/constraint/DelegationAbsoluteTime.class
net/jini/core/constraint/DelegationRelativeTime.class
net/jini/core/constraint/Integrity.class
net/jini/core/constraint/InvocationConstraint.class
net/jini/core/constraint/InvocationConstraints.class
net/jini/core/constraint/MethodConstraints.class
net/jini/core/constraint/RelativeTimeConstraint.class
net/jini/core/constraint/RemoteMethodControl.class
net/jini/core/constraint/ServerAuthentication.class
net/jini/core/constraint/ServerMinPrincipal.class
net/jini/core/discovery/
net/jini/core/discovery/LookupLocator$1.class
net/jini/core/discovery/LookupLocator.class
net/jini/core/entry/
net/jini/core/entry/Entry.class
net/jini/core/entry/UnusableEntryException.class
net/jini/core/event/
net/jini/core/event/EventRegistration.class
net/jini/core/event/RemoteEvent.class
net/jini/core/event/RemoteEventListener.class
net/jini/core/event/UnknownEventException.class
net/jini/core/lease/
net/jini/core/lease/Lease.class
net/jini/core/lease/LeaseDeniedException.class
net/jini/core/lease/LeaseException.class
net/jini/core/lease/LeaseMap.class
net/jini/core/lease/LeaseMapException.class
net/jini/core/lease/UnknownLeaseException.class
net/jini/core/lookup/
net/jini/core/lookup/ServiceEvent.class
net/jini/core/lookup/ServiceID.class
net/jini/core/lookup/ServiceItem.class
net/jini/core/lookup/ServiceMatches.class
net/jini/core/lookup/ServiceRegistrar.class
net/jini/core/lookup/ServiceRegistration.class
net/jini/core/lookup/ServiceTemplate.class
net/jini/core/transaction/
net/jini/core/transaction/CannotAbortException.class
net/jini/core/transaction/CannotCommitException.class
net/jini/core/transaction/CannotJoinException.class
net/jini/core/transaction/CannotNestException.class
net/jini/core/transaction/NestableTransaction$Created.class
net/jini/core/transaction/NestableTransaction.class
net/jini/core/transaction/TimeoutExpiredException.class
net/jini/core/transaction/Transaction$Created.class
net/jini/core/transaction/Transaction.class
net/jini/core/transaction/TransactionException.class
net/jini/core/transaction/TransactionFactory.class
net/jini/core/transaction/UnknownTransactionException.class
net/jini/core/transaction/server/
net/jini/core/transaction/server/CrashCountException.class
net/jini/core/transaction/server/NestableServerTransaction.class
net/jini/core/transaction/server/NestableTransactionManager.class
net/jini/core/transaction/server/ServerTransaction.class
net/jini/core/transaction/server/TransactionConstants.class
net/jini/core/transaction/server/TransactionManager$Created.class
net/jini/core/transaction/server/TransactionManager.class
net/jini/core/transaction/server/TransactionParticipant.class
net/jini/discovery/ConstrainableLookupLocator$1.class
net/jini/discovery/ConstrainableLookupLocator.class
net/jini/discovery/ConstrainableLookupLocatorTrustVerifier.class
net/jini/export/
net/jini/export/ExportPermission.class
net/jini/export/Exporter.class
net/jini/export/ProxyAccessor.class
net/jini/export/ServerContext$1.class
net/jini/export/ServerContext$Spi.class
net/jini/export/ServerContext.class
net/jini/id/
net/jini/id/ReferentUuid.class
net/jini/id/ReferentUuids.class
net/jini/id/Uuid.class
net/jini/id/UuidFactory$Impl.class
net/jini/id/UuidFactory.class
net/jini/iiop/
net/jini/iiop/IiopExporter.class
net/jini/io/
net/jini/io/MarshalInputStream.class
net/jini/io/MarshalOutputStream.class
net/jini/io/MarshalledInstance$1.class
net/jini/io/MarshalledInstance$FromMOInputStream.class
net/jini/io/MarshalledInstance$MarshalledInstanceInputStream.class
net/jini/io/MarshalledInstance$MarshalledInstanceOutputStream.class
net/jini/io/MarshalledInstance$ToMOInputStream.class
net/jini/io/MarshalledInstance.class
net/jini/io/MarshalledObject.class
net/jini/io/ObjectStreamContext.class
net/jini/io/UnsupportedConstraintException.class
net/jini/io/context/
net/jini/io/context/AcknowledgmentSource$Listener.class
net/jini/io/context/AcknowledgmentSource.class
net/jini/io/context/ClientHost.class
net/jini/io/context/ClientSubject.class
net/jini/io/context/ContextPermission.class
net/jini/io/context/IntegrityEnforcement.class
net/jini/jeri/
net/jini/jeri/AbstractILFactory$1.class
net/jini/jeri/AbstractILFactory.class
net/jini/jeri/BasicILFactory.class
net/jini/jeri/BasicInvocationDispatcher$1.class
net/jini/jeri/BasicInvocationDispatcher$2.class
net/jini/jeri/BasicInvocationDispatcher.class
net/jini/jeri/BasicInvocationHandler$1.class
net/jini/jeri/BasicInvocationHandler$Failure.class
net/jini/jeri/BasicInvocationHandler.class
net/jini/jeri/BasicJeriExporter$ImplContainer.class
net/jini/jeri/BasicJeriExporter.class
net/jini/jeri/BasicJeriTrustVerifier$1.class
net/jini/jeri/BasicJeriTrustVerifier.class
net/jini/jeri/BasicObjectEndpoint$1.class
net/jini/jeri/BasicObjectEndpoint$AckListener.class
net/jini/jeri/BasicObjectEndpoint$DgcBatchContext.class
net/jini/jeri/BasicObjectEndpoint.class
net/jini/jeri/Endpoint.class
net/jini/jeri/InboundRequest.class
net/jini/jeri/InvocationDispatcher.class
net/jini/jeri/InvocationLayerFactory$Instances.class
net/jini/jeri/InvocationLayerFactory.class
net/jini/jeri/ObjectEndpoint.class
net/jini/jeri/OutboundRequest.class
net/jini/jeri/OutboundRequestIterator.class
net/jini/jeri/ProxyTrustILFactory.class
net/jini/jeri/RequestDispatcher.class
net/jini/jeri/ServerCapabilities.class
net/jini/jeri/ServerEndpoint$ListenContext.class
net/jini/jeri/ServerEndpoint$ListenCookie.class
net/jini/jeri/ServerEndpoint$ListenEndpoint.class
net/jini/jeri/ServerEndpoint$ListenHandle.class
net/jini/jeri/ServerEndpoint.class
net/jini/jeri/connection/
net/jini/jeri/connection/Connection.class
net/jini/jeri/connection/ConnectionEndpoint.class
net/jini/jeri/connection/ConnectionManager$Outbound$Input.class
net/jini/jeri/connection/ConnectionManager$Outbound.class
net/jini/jeri/connection/ConnectionManager$OutboundMux.class
net/jini/jeri/connection/ConnectionManager$Reaper.class
net/jini/jeri/connection/ConnectionManager$ReqIterator.class
net/jini/jeri/connection/ConnectionManager.class
net/jini/jeri/connection/InboundRequestHandle.class
net/jini/jeri/connection/OutboundRequestHandle.class
net/jini/jeri/connection/ServerConnection.class
net/jini/jeri/connection/ServerConnectionManager$Dispatcher.class
net/jini/jeri/connection/ServerConnectionManager$Inbound.class
net/jini/jeri/connection/ServerConnectionManager$InboundMux.class
net/jini/jeri/connection/ServerConnectionManager.class
net/jini/jeri/http/
net/jini/jeri/http/Constraints$Distilled.class
net/jini/jeri/http/Constraints.class
net/jini/jeri/http/HttpEndpoint$1.class
net/jini/jeri/http/HttpEndpoint$2.class
net/jini/jeri/http/HttpEndpoint$3.class
net/jini/jeri/http/HttpEndpoint$4.class
net/jini/jeri/http/HttpEndpoint$5.class
net/jini/jeri/http/HttpEndpoint$6.class
net/jini/jeri/http/HttpEndpoint$Connection.class
net/jini/jeri/http/HttpEndpoint$ConnectionAction.class
net/jini/jeri/http/HttpEndpoint$SocketFactoryAdapter.class
net/jini/jeri/http/HttpEndpoint.class
net/jini/jeri/http/HttpServerEndpoint$1.class
net/jini/jeri/http/HttpServerEndpoint$LE$Cookie.class
net/jini/jeri/http/HttpServerEndpoint$LE.class
net/jini/jeri/http/HttpServerEndpoint$LH$1.class
net/jini/jeri/http/HttpServerEndpoint$LH$2.class
net/jini/jeri/http/HttpServerEndpoint$LH$Connection.class
net/jini/jeri/http/HttpServerEndpoint$LH.class
net/jini/jeri/http/HttpServerEndpoint.class
net/jini/jeri/kerberos/
net/jini/jeri/kerberos/KerberosEndpoint$1.class
net/jini/jeri/kerberos/KerberosEndpoint$CacheKey.class
net/jini/jeri/kerberos/KerberosEndpoint$ConnectionEndpointImpl.class
net/jini/jeri/kerberos/KerberosEndpoint$ConnectionImpl$1.class
net/jini/jeri/kerberos/KerberosEndpoint$ConnectionImpl.class
net/jini/jeri/kerberos/KerberosEndpoint$KerberosEndpointInternals$1.class
net/jini/jeri/kerberos/KerberosEndpoint$KerberosEndpointInternals.class
net/jini/jeri/kerberos/KerberosEndpoint$RequestHandleImpl$1.class
net/jini/jeri/kerberos/KerberosEndpoint$RequestHandleImpl$2.class
net/jini/jeri/kerberos/KerberosEndpoint$RequestHandleImpl.class
net/jini/jeri/kerberos/KerberosEndpoint.class
net/jini/jeri/kerberos/KerberosServerEndpoint$1.class
net/jini/jeri/kerberos/KerberosServerEndpoint$2.class
net/jini/jeri/kerberos/KerberosServerEndpoint$3.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ConnectionHandler$1$1.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ConnectionHandler$1.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ConnectionHandler$2.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ConnectionHandler.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenCookieImpl.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenEndpointImpl$1.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenEndpointImpl.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenHandleImpl$1.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenHandleImpl$2.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ListenHandleImpl.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ServerConnectionImpl$CacheKey.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ServerConnectionImpl$InboundRequestHandleImpl.class
net/jini/jeri/kerberos/KerberosServerEndpoint$ServerConnectionImpl.class
net/jini/jeri/kerberos/KerberosServerEndpoint.class
net/jini/jeri/kerberos/KerberosTrustVerifier.class
net/jini/jeri/kerberos/KerberosUtil$1.class
net/jini/jeri/kerberos/KerberosUtil$Config.class
net/jini/jeri/kerberos/KerberosUtil$ConfigIter.class
net/jini/jeri/kerberos/KerberosUtil$Connection.class
net/jini/jeri/kerberos/KerberosUtil$ConnectionInputStream.class
net/jini/jeri/kerberos/KerberosUtil$ConnectionOutputStream.class
net/jini/jeri/kerberos/KerberosUtil$SoftCache$LRUHashMap.class
net/jini/jeri/kerberos/KerberosUtil$SoftCache$ValueCell.class
net/jini/jeri/kerberos/KerberosUtil$SoftCache.class
net/jini/jeri/kerberos/KerberosUtil.class
net/jini/jeri/ssl/
net/jini/jeri/ssl/AuthManager.class
net/jini/jeri/ssl/CallContext.class
net/jini/jeri/ssl/ClientAuthManager.class
net/jini/jeri/ssl/ConfidentialityStrength.class
net/jini/jeri/ssl/ConnectionContext.class
net/jini/jeri/ssl/FilterX509TrustManager$1.class
net/jini/jeri/ssl/FilterX509TrustManager.class
net/jini/jeri/ssl/HttpsEndpoint$1.class
net/jini/jeri/ssl/HttpsEndpoint$EndpointInfo.class
net/jini/jeri/ssl/HttpsEndpoint$HttpClient.class
net/jini/jeri/ssl/HttpsEndpoint$HttpsConnection$1.class
net/jini/jeri/ssl/HttpsEndpoint$HttpsConnection.class
net/jini/jeri/ssl/HttpsEndpoint$HttpsEndpointImpl$1.class
net/jini/jeri/ssl/HttpsEndpoint$HttpsEndpointImpl.class
net/jini/jeri/ssl/HttpsEndpoint$HttpsOutboundRequest.class
net/jini/jeri/ssl/HttpsEndpoint$Reaper.class
net/jini/jeri/ssl/HttpsEndpoint.class
net/jini/jeri/ssl/HttpsServerEndpoint$1.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpServer.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpsInboundRequest.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpsListenEndpoint.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpsListenHandle.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpsRequestDispatcher.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl$HttpsServerConnection.class
net/jini/jeri/ssl/HttpsServerEndpoint$HttpsServerEndpointImpl.class
net/jini/jeri/ssl/HttpsServerEndpoint.class
net/jini/jeri/ssl/ServerAuthManager.class
net/jini/jeri/ssl/SslConnection.class
net/jini/jeri/ssl/SslEndpoint$SslEndpointInternals$1.class
net/jini/jeri/ssl/SslEndpoint$SslEndpointInternals.class
net/jini/jeri/ssl/SslEndpoint.class
net/jini/jeri/ssl/SslEndpointImpl$1.class
net/jini/jeri/ssl/SslEndpointImpl$ComparableConnectionContext.class
net/jini/jeri/ssl/SslEndpointImpl$ConnectionContextCache.class
net/jini/jeri/ssl/SslEndpointImpl$ConnectionsIterator.class
net/jini/jeri/ssl/SslEndpointImpl$CopyOnRemoveList.class
net/jini/jeri/ssl/SslEndpointImpl$ExceptionOutboundRequestIterator.class
net/jini/jeri/ssl/SslEndpointImpl.class
net/jini/jeri/ssl/SslServerEndpoint.class
net/jini/jeri/ssl/SslServerEndpointImpl$1.class
net/jini/jeri/ssl/SslServerEndpointImpl$2.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslListenCookie.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslListenEndpoint.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslListenHandle$1.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslListenHandle$2.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslListenHandle.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslServerConnection$1.class
net/jini/jeri/ssl/SslServerEndpointImpl$SslServerConnection.class
net/jini/jeri/ssl/SslServerEndpointImpl.class
net/jini/jeri/ssl/SslTrustVerifier.class
net/jini/jeri/ssl/SubjectCredentials$CertificateMatcher.class
net/jini/jeri/ssl/SubjectCredentials$GetAllPrivateCredentialsAction.class
net/jini/jeri/ssl/SubjectCredentials$GetPrivateCredentialAction.class
net/jini/jeri/ssl/SubjectCredentials.class
net/jini/jeri/ssl/Utilities$1.class
net/jini/jeri/ssl/Utilities$ClientKey.class
net/jini/jeri/ssl/Utilities$SSLContextInfo.class
net/jini/jeri/ssl/Utilities$ServerKey.class
net/jini/jeri/ssl/Utilities$Value.class
net/jini/jeri/ssl/Utilities.class
net/jini/jeri/tcp/
net/jini/jeri/tcp/Constraints$Distilled.class
net/jini/jeri/tcp/Constraints.class
net/jini/jeri/tcp/TcpEndpoint$1.class
net/jini/jeri/tcp/TcpEndpoint$ConnectionEndpointImpl.class
net/jini/jeri/tcp/TcpEndpoint$ConnectionImpl.class
net/jini/jeri/tcp/TcpEndpoint$Handle.class
net/jini/jeri/tcp/TcpEndpoint.class
net/jini/jeri/tcp/TcpServerEndpoint$1.class
net/jini/jeri/tcp/TcpServerEndpoint$LE$Cookie.class
net/jini/jeri/tcp/TcpServerEndpoint$LE.class
net/jini/jeri/tcp/TcpServerEndpoint$LH$1.class
net/jini/jeri/tcp/TcpServerEndpoint$LH$2.class
net/jini/jeri/tcp/TcpServerEndpoint$LH$ServerConnectionImpl$1.class
net/jini/jeri/tcp/TcpServerEndpoint$LH$ServerConnectionImpl.class
net/jini/jeri/tcp/TcpServerEndpoint$LH.class
net/jini/jeri/tcp/TcpServerEndpoint.class
net/jini/jrmp/
net/jini/jrmp/JrmpExporter.class
net/jini/jrmp/JrmpServerContext.class
net/jini/loader/
net/jini/loader/ClassAnnotation.class
net/jini/loader/ClassLoading$1.class
net/jini/loader/ClassLoading$2.class
net/jini/loader/ClassLoading.class
net/jini/loader/DownloadPermission.class
net/jini/loader/pref/
net/jini/loader/pref/PreferredClassLoader$1.class
net/jini/loader/pref/PreferredClassLoader$2.class
net/jini/loader/pref/PreferredClassLoader$3.class
net/jini/loader/pref/PreferredClassLoader$4.class
net/jini/loader/pref/PreferredClassLoader.class
net/jini/loader/pref/PreferredClassProvider$1.class
net/jini/loader/pref/PreferredClassProvider$2.class
net/jini/loader/pref/PreferredClassProvider$3.class
net/jini/loader/pref/PreferredClassProvider$4.class
net/jini/loader/pref/PreferredClassProvider$5.class
net/jini/loader/pref/PreferredClassProvider$LoaderEntry.class
net/jini/loader/pref/PreferredClassProvider$LoaderEntryHolder.class
net/jini/loader/pref/PreferredClassProvider$LoaderKey.class
net/jini/loader/pref/PreferredClassProvider.class
net/jini/loader/pref/PreferredFactoryClassLoader.class
net/jini/loader/pref/RequireDlPermProvider.class
net/jini/security/
net/jini/security/AccessPermission.class
net/jini/security/AuthenticationPermission$AuthenticationPermissionCollection.class
net/jini/security/AuthenticationPermission$Data.class
net/jini/security/AuthenticationPermission.class
net/jini/security/BasicProxyPreparer.class
net/jini/security/GrantPermission$1.class
net/jini/security/GrantPermission$GrantPermissionCollection.class
net/jini/security/GrantPermission$Implier.class
net/jini/security/GrantPermission$PermissionInfo.class
net/jini/security/GrantPermission.class
net/jini/security/IntegrityVerifier.class
net/jini/security/ProxyPreparer.class
net/jini/security/Security$1.class
net/jini/security/Security$2.class
net/jini/security/Security$3.class
net/jini/security/Security$4.class
net/jini/security/Security$5.class
net/jini/security/Security$6.class
net/jini/security/Security$7.class
net/jini/security/Security$8.class
net/jini/security/Security$ClassContextAccess.class
net/jini/security/Security$Context$1.class
net/jini/security/Security$Context.class
net/jini/security/Security.class
net/jini/security/SecurityContext.class
net/jini/security/TrustVerifier$Context.class
net/jini/security/TrustVerifier.class
net/jini/security/VerifyingProxyPreparer.class
net/jini/security/policy/
net/jini/security/policy/DynamicPolicy.class
net/jini/security/policy/DynamicPolicyProvider$1.class
net/jini/security/policy/DynamicPolicyProvider$2.class
net/jini/security/policy/DynamicPolicyProvider$3.class
net/jini/security/policy/DynamicPolicyProvider$DomainPermissions.class
net/jini/security/policy/DynamicPolicyProvider$Grants$PrincipalGrants.class
net/jini/security/policy/DynamicPolicyProvider$Grants.class
net/jini/security/policy/DynamicPolicyProvider$WeakGroup$1.class
net/jini/security/policy/DynamicPolicyProvider$WeakGroup$Node.class
net/jini/security/policy/DynamicPolicyProvider$WeakGroup.class
net/jini/security/policy/DynamicPolicyProvider.class
net/jini/security/policy/PolicyFileProvider$1.class
net/jini/security/policy/PolicyFileProvider.class
net/jini/security/policy/PolicyInitializationException.class
net/jini/security/policy/SecurityContextSource.class
net/jini/security/policy/UmbrellaGrantPermission.class
net/jini/security/proxytrust/
net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext$1$1.class
net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext$1.class
net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext$2.class
net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext$Combiner.class
net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext.class
net/jini/security/proxytrust/ProxyTrust.class
net/jini/security/proxytrust/ProxyTrustExporter$ProxyTrustImpl.class
net/jini/security/proxytrust/ProxyTrustExporter$Reaper.class
net/jini/security/proxytrust/ProxyTrustExporter$WeakRef.class
net/jini/security/proxytrust/ProxyTrustExporter.class
net/jini/security/proxytrust/ProxyTrustInvocationHandler.class
net/jini/security/proxytrust/ProxyTrustIterator.class
net/jini/security/proxytrust/ProxyTrustVerifier$1.class
net/jini/security/proxytrust/ProxyTrustVerifier$2.class
net/jini/security/proxytrust/ProxyTrustVerifier$3.class
net/jini/security/proxytrust/ProxyTrustVerifier$4.class
net/jini/security/proxytrust/ProxyTrustVerifier$5.class
net/jini/security/proxytrust/ProxyTrustVerifier$6.class
net/jini/security/proxytrust/ProxyTrustVerifier$7.class
net/jini/security/proxytrust/ProxyTrustVerifier$MOStream$1.class
net/jini/security/proxytrust/ProxyTrustVerifier$MOStream.class
net/jini/security/proxytrust/ProxyTrustVerifier.class
net/jini/security/proxytrust/ServerProxyTrust.class
net/jini/security/proxytrust/SingletonProxyTrustIterator.class
net/jini/security/proxytrust/TrustEquivalence.class
net/jini/security/proxytrust/UntrustedObjectSecurityContext.class
net/jini/url/
net/jini/url/file/
net/jini/url/file/FileIntegrityVerifier.class
net/jini/url/httpmd/
net/jini/url/httpmd/DelegatingHttpURLConnection.class
net/jini/url/httpmd/Handler.class
net/jini/url/httpmd/HttpmdIntegrityVerifier.class
net/jini/url/httpmd/HttpmdURLConnection.class
net/jini/url/httpmd/HttpmdUtil$1.class
net/jini/url/httpmd/HttpmdUtil.class
net/jini/url/httpmd/MdInputStream.class
net/jini/url/httpmd/WrongMessageDigestException.class
net/jini/url/https/
net/jini/url/https/HttpsIntegrityVerifier.class
Re: [Dicuss] Build Structure
Posted by Dennis Reedy <de...@gmail.com>.
Greg,
Discussion ensues.
A little tangent here that might be of interest. I worked on modularizing Blitz with Dawid Loubser, if you're interested in seeing how that ended up (pretty much follows the conventions being discussed), check it out here https://github.com/DawidLoubser/blitz-javaspaces-modularised
Regards
Dennis
On Feb 12, 2014, at 516PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> Hi Dennis:
>
> Some discussion inline…
>
> Greg Trasuk
>
> On Feb 12, 2014, at 4:16 PM, Dennis Reedy <de...@gmail.com> wrote:
>
>> Greg,
>>
>> I think how the River project is structured, built and tested becomes a recipe for how developers that use River can begin to create their own projects. So IMO its something to care about. As you point out, the current approach is based on decisions made over a decade ago and there are reasons to change (as have been pointed out).
>
> Is the Tomcat source code a recipe for how to structure web applications?
Right, but Tomcat is not a web application.
> All I’m saying is that the purpose of River’s build system is to build River, and nothing more. So let’s think clearly about what we gain by restructuring it.
I agree on this generally but only for river-core components. When it comes to River services, we should set guidance by showing how the project builds it's services. IMO this is a plain and simple win for developers curious on they should build and test their services.
> The biggest advantage I see is making it easier to maintain and update the pieces separately (e.g. update Outrigger to use an open-source data store instead of SnapLogStore, or create a clustered JavaSpace). Eventually I think that leads to multiple deliverables with different release cadences, but we certainly don’t need to start out that way.
>
> In any case, I think the recipe for how to develop applications has to be shown with good examples,
Sure, good examples are always important.
> not River’s build system. For application developers, the mechanism to build the artifacts that go into Central isn’t important.
Building River services and deploying to central have nothing to do with each other.
> As they say, “People who like laws and sausages probably shouldn’t watch either one being made”.
>
>>
>> If we choose to adopt conventions that produce a single jar per module,
>
> Apart from my griping about having a lot of IDE projects, I think a single jar per module is the way to go. That will be much more clear about why the modules exist, and we’ll avoid any possibility of having the same class in different jar files (which we currently do have).
>
>> and that each module represent a basic architectural element of a distributed service, then we can begin to break out and organize the project. What I had started to do was to break out River as follows:
>>
>> apache-river/
>> river-core/
>> jsk-dl/
>> jsk-lib/
>> jsk-platform/
>> jsk-resources/
>> serviceui/
>>
>
> Don’t forget jsk-policy.jar
Right, oversight on my part and hand typing this in I knew I was bound to miss something :/
>
> Also, does anyone remember the rationale as to what goes into jsk-lib as opposed to jsk-patform? Right now there’s some overlap between them.
Whats the overlap?
> I thought the idea was to just have jsk-platform.jar.
>
>> river-services/ [1]
>> reggie/
>> reggie-proxy/
>> reggie-impl/
>> outrigger/
>> outrigger-proxy/
>> outrigger-impl/
>> outrigger-snaplogstore/
>> mahalo/
>> mahalo-proxy/
>> mahalo-impl/
>> mercury/
>> mercury-proxy/
>> mercury-impl/
>>
>
> Minor thing - could we keep it as “reggie-dl”, etc, rather than “reggie-proxy”? To me, *-dl expresses the intention a little better, since it’s all the classes that might need to be downloaded to the client, which might include other support in addition to the proxy. Either naming will work, but it would be good to be consistent.
The proxy module calls out quite clearly what the module contains, and that one should never include a proxy module in one's classpath. However, if a service has an api module, that would become a classpath dependency for using a service, and have that service's proxy loaded dynamically (downloaded or loaded from the file system).
To me I originally found the -dl.jar naming confusing. To the un-initiated, it is not obvious. Unless I know that dl means download, I have no idea what the dl is, encompasses or means. Using proxy seems quite clear.
> In building modules for a container, it’s kind of nice to be able to pickup on the name of the jar to indicate if it needs to go in the codebase annotation.
And proxy fits the bill quite nicely IMO. My service's annotation is the proxy, and clients use the api as a classpath dependency.
>
>>
>> river-start/
>>
>> river-tools/
>> browser/
>> classserver/
>>
>
> I’d almost put class server into the starter framework. I don’t think it’s useful outside the service-starter.
Meh. I use ServiceStarter, but not classerver. I use Rio's Webster. Some use Tomcat, some use Jetty. I wouldn't couple classerver with starter.
>
> The browser is actually (in the current structure anyway) in the ‘examples’ directory. If you’re interested, I’ve already isolated it in the container build. See https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser;h=cdb48103dced2273fc62ab3857676afec3861ef2;hb=HEAD and https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser-module;h=1a5897a11e1419055eefdfe6d439bd2d2f4d1cb0;hb=HEAD.
Most have co-opted the browser, isolating it should not be an issue.
>
>> river-integration-tests
>>
>
> I agree that the integration tests should probably stay as a separate module. As time goes on it would be good to have unit tests in the other modules, too.
You want to ideally have unit tests coupled with each module.
>
>> Under each module (example reggie-proxy), we would have:
>>
>> src/
>> main/
>> java/
>> groovy/
>> (other languages...)
>> resources/
>> test/
>> java/
>> groovy/
>> (other languages...)
>> resources/
>>
>> I think the most difficult and time consuming effort would be to try and merge in the current unit tests into each module. AFAIK, mots of the tests are integration tests, so putting them in their own module makes sense.
>>
>> We still have one deliverable, all we need to do is "assemble" the project into a distribution. This is a fairly simple thing to do with Maven (I'm sure it's not that difficult to do with Gradle either).
>>
>> Regards
>>
>> Dennis
>>
>> 1. In most cases an api module is not required for River core services since the API is defined is jsk-dl
>>
>
> That’s probably open to argument. For example, is JavaSpace a “core” API? It always seemed to me like it landed inside Jini because it needed a home (I recall that at one time it was a separate project), but it seems more like an application API. I’m not saying it _should_ or _shouldn’t_ be split out, but it’s something to think about. Things like Registrar, however, seem to be pretty “core”.
Well, it is net.jini.space.JavaSpace, are you advocating to move it out of the net.jini namespace? Or, do you think that we should move all of the River service api's out of jsk-lib and put them specifically into an api module for each respective service?
However, Outrigger is a contributed implementation of JavaSpace(05), so it does not make sense to put it into the outrigger module?
Perhaps create a separate river-api module that includes all of net.jini service apis (Registrar, JavaSpace(05), TransactionManager,...). That might be a good idea.
>
> Overall, a good start on the modules. We’ll need to settle on a tool (maven, Gradle, Ant, etc). I’m kind of with Simon on this - Maven is pretty standard, and I’d probably vote for it in the absence of strong arguments for a different build tool. Although I did notice as I was doing the container work that it sometimes does impose limits on the actual application (for example, I couldn’t for the life of me figure a clean way to get it to generate a module with a “.ssar” extension without writing a plugin, which I wasn’t at the time aware how to do, so I changed the deployment module to “.jar”).
For me, Maven would be the quickest.
>
> I’m assuming we’d wait to modularize until Peter declares ‘qa_refactor’ done, and merges it back into the trunk?
Sure, or do the work in qa_refactor (up to Peter). I'd also recommend that as part of this we change the com.sun.jini namespace to org.apache.river, and make sure that for each module, we follow consistent package naming conventions:
org.apache.river.<module-name>.api
org.apache.river.<module-name>.proxy
api: org.apache.river.<module-name>.impl
Lastly, I'd alter my original work to change river-core to:
river-core/
river-dl/
river-lib/
river-platform/
river-resources/
river-policy
river-serviceui/
Re: [Dicuss] Build Structure
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Dennis:
Some discussion inline…
Greg Trasuk
On Feb 12, 2014, at 4:16 PM, Dennis Reedy <de...@gmail.com> wrote:
> Greg,
>
> I think how the River project is structured, built and tested becomes a recipe for how developers that use River can begin to create their own projects. So IMO its something to care about. As you point out, the current approach is based on decisions made over a decade ago and there are reasons to change (as have been pointed out).
Is the Tomcat source code a recipe for how to structure web applications? All I’m saying is that the purpose of River’s build system is to build River, and nothing more. So let’s think clearly about what we gain by restructuring it. The biggest advantage I see is making it easier to maintain and update the pieces separately (e.g. update Outrigger to use an open-source data store instead of SnapLogStore, or create a clustered JavaSpace). Eventually I think that leads to multiple deliverables with different release cadences, but we certainly don’t need to start out that way.
In any case, I think the recipe for how to develop applications has to be shown with good examples, not River’s build system. For application developers, the mechanism to build the artifacts that go into Central isn’t important. As they say, “People who like laws and sausages probably shouldn’t watch either one being made”.
>
> If we choose to adopt conventions that produce a single jar per module,
Apart from my griping about having a lot of IDE projects, I think a single jar per module is the way to go. That will be much more clear about why the modules exist, and we’ll avoid any possibility of having the same class in different jar files (which we currently do have).
> and that each module represent a basic architectural element of a distributed service, then we can begin to break out and organize the project. What I had started to do was to break out River as follows:
>
> apache-river/
> river-core/
> jsk-dl/
> jsk-lib/
> jsk-platform/
> jsk-resources/
> serviceui/
>
Don’t forget jsk-policy.jar
Also, does anyone remember the rationale as to what goes into jsk-lib as opposed to jsk-patform? Right now there’s some overlap between them. I thought the idea was to just have jsk-platform.jar.
> river-services/ [1]
> reggie/
> reggie-proxy/
> reggie-impl/
> outrigger/
> outrigger-proxy/
> outrigger-impl/
> outrigger-snaplogstore/
> mahalo/
> mahalo-proxy/
> mahalo-impl/
> mercury/
> mercury-proxy/
> mercury-impl/
>
Minor thing - could we keep it as “reggie-dl”, etc, rather than “reggie-proxy”? To me, *-dl expresses the intention a little better, since it’s all the classes that might need to be downloaded to the client, which might include other support in addition to the proxy. Either naming will work, but it would be good to be consistent. In building modules for a container, it’s kind of nice to be able to pickup on the name of the jar to indicate if it needs to go in the codebase annotation.
>
> river-start/
>
> river-tools/
> browser/
> classserver/
>
I’d almost put class server into the starter framework. I don’t think it’s useful outside the service-starter.
The browser is actually (in the current structure anyway) in the ‘examples’ directory. If you’re interested, I’ve already isolated it in the container build. See https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser;h=cdb48103dced2273fc62ab3857676afec3861ef2;hb=HEAD and https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser-module;h=1a5897a11e1419055eefdfe6d439bd2d2f4d1cb0;hb=HEAD.
> river-integration-tests
>
I agree that the integration tests should probably stay as a separate module. As time goes on it would be good to have unit tests in the other modules, too.
> Under each module (example reggie-proxy), we would have:
>
> src/
> main/
> java/
> groovy/
> (other languages...)
> resources/
> test/
> java/
> groovy/
> (other languages...)
> resources/
>
> I think the most difficult and time consuming effort would be to try and merge in the current unit tests into each module. AFAIK, mots of the tests are integration tests, so putting them in their own module makes sense.
>
> We still have one deliverable, all we need to do is "assemble" the project into a distribution. This is a fairly simple thing to do with Maven (I'm sure it's not that difficult to do with Gradle either).
>
> Regards
>
> Dennis
>
> 1. In most cases an api module is not required for River core services since the API is defined is jsk-dl
>
That’s probably open to argument. For example, is JavaSpace a “core” API? It always seemed to me like it landed inside Jini because it needed a home (I recall that at one time it was a separate project), but it seems more like an application API. I’m not saying it _should_ or _shouldn’t_ be split out, but it’s something to think about. Things like Registrar, however, seem to be pretty “core”.
Overall, a good start on the modules. We’ll need to settle on a tool (maven, Gradle, Ant, etc). I’m kind of with Simon on this - Maven is pretty standard, and I’d probably vote for it in the absence of strong arguments for a different build tool. Although I did notice as I was doing the container work that it sometimes does impose limits on the actual application (for example, I couldn’t for the life of me figure a clean way to get it to generate a module with a “.ssar” extension without writing a plugin, which I wasn’t at the time aware how to do, so I changed the deployment module to “.jar”).
I’m assuming we’d wait to modularize until Peter declares ‘qa_refactor’ done, and merges it back into the trunk?
>
> On Feb 12, 2014, at 1034AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>>
>>
>> Hi all:
>>
>> I’d just like to sound a quiet note of caution here.
>>
>> Everyone seems to be in agreement that the current build structure is problematic. After all, it was fundamentally designed around the ‘make’ tool 15 years ago.
>>
>> However… Altering the build structure and switching to a new tool (Maven, Gradle, Ant/Ivy, etc) will be a _lot_ of work, and we’ll be living with it for a while. Let’s not jump to conclusions without a good discussion.
>>
>> So let’s start with some reflection…
>>
>> It’s worth asking “who cares about the build system?” Let’s be clear about something: the vast majority of developers should be using the jars out of Maven Central, or at most running the River build once to build from source. It’s only us, on the River project, who are using the build system. That being the case, perhaps we ought to talk about what we intend to do, before we make any decisions or expend a lot of effort.
>>
>> Are we thinking in terms of runtime containers or execution environments? The core build doesn’t matter then. For example, the container work in progress (https://git-wip-us.apache.org/repos/asf/river-container.git) builds with Maven, but uses the River dependencies published in Maven Central.
>>
>> Are we planning separate modules for Reggie, Mahalo and Outrigger? Those new modules will need a build/integration test system, and we should discuss that. Worth mentioning that so long as the jars go into Maven Central or some other dependency management system, the modules don’t actually need to have the same build tool (although consistency is probably good).
>>
>> What else are we planning? Chances are, it should go into a different module.
>>
>> Which brings me to another topic - how should we manage multiple deliverables? Could I suggest the following “deliverable sets”, which would each have different releases?
>>
>> - Jini Core - Basically what’s currently in jsk-platform.jar
>> - Registrar Service Module
>> - Transaction Service Module
>> - JavaSpaces Service Module
>> - note - I’m not sure if Mercury, fiddler, etc are used all that much, but if so, they could have their own modules
>> - Jini Application Server (river-container packaged with the infrastructure services)
>> - other - Rio? Anything else?
>>
>> The actual set of modules is open to discussion of course, but I’m thinking we need to support more than one “deliverable”. Not quite “sub projects”, since the governance doesn’t need to be separate, but I think separate source repositories and releases.
>>
>> In any case, my big suggestion is let’s not take these decisions lightly. There’s no hurry.
>>
>> Cheers,
>>
>> Greg.
>>
>> On Feb 12, 2014, at 5:31 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>>
>>> On 12-02-14 11:28, Simon IJskes - QCG wrote:
>>>> Ok,
>>>>
>>>> what i have seen is:
>>>>
>>>> - maven / gradle / ivy
>>>> - convention (submodules structure)
>>>> - 1 river or submodules (reedy-trasuk)
>>>>
>>>> Do we need to discuss this further, or do we need a vote on the sub-items.
>>>>
>>>> Gr. Simon
>>>>
>>>>
>>>
>>> in order of pref:
>>> - maven
>>> - gradle
>>> - ivy
>>>
>>> conventions:
>>> +1
>>>
>>> submodules:
>>> +0
>>>
>>> Gr. Simon
>>>
>>> --
>>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
>
Re: [Dicuss] Build Structure
Posted by Dennis Reedy <de...@gmail.com>.
Greg,
I think how the River project is structured, built and tested becomes a recipe for how developers that use River can begin to create their own projects. So IMO its something to care about. As you point out, the current approach is based on decisions made over a decade ago and there are reasons to change (as have been pointed out).
If we choose to adopt conventions that produce a single jar per module, and that each module represent a basic architectural element of a distributed service, then we can begin to break out and organize the project. What I had started to do was to break out River as follows:
apache-river/
river-core/
jsk-dl/
jsk-lib/
jsk-platform/
jsk-resources/
serviceui/
river-services/ [1]
reggie/
reggie-proxy/
reggie-impl/
outrigger/
outrigger-proxy/
outrigger-impl/
outrigger-snaplogstore/
mahalo/
mahalo-proxy/
mahalo-impl/
mercury/
mercury-proxy/
mercury-impl/
river-start/
river-tools/
browser/
classserver/
river-integration-tests
Under each module (example reggie-proxy), we would have:
src/
main/
java/
groovy/
(other languages...)
resources/
test/
java/
groovy/
(other languages...)
resources/
I think the most difficult and time consuming effort would be to try and merge in the current unit tests into each module. AFAIK, mots of the tests are integration tests, so putting them in their own module makes sense.
We still have one deliverable, all we need to do is "assemble" the project into a distribution. This is a fairly simple thing to do with Maven (I'm sure it's not that difficult to do with Gradle either).
Regards
Dennis
1. In most cases an api module is not required for River core services since the API is defined is jsk-dl
On Feb 12, 2014, at 1034AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>
> Hi all:
>
> I’d just like to sound a quiet note of caution here.
>
> Everyone seems to be in agreement that the current build structure is problematic. After all, it was fundamentally designed around the ‘make’ tool 15 years ago.
>
> However… Altering the build structure and switching to a new tool (Maven, Gradle, Ant/Ivy, etc) will be a _lot_ of work, and we’ll be living with it for a while. Let’s not jump to conclusions without a good discussion.
>
> So let’s start with some reflection…
>
> It’s worth asking “who cares about the build system?” Let’s be clear about something: the vast majority of developers should be using the jars out of Maven Central, or at most running the River build once to build from source. It’s only us, on the River project, who are using the build system. That being the case, perhaps we ought to talk about what we intend to do, before we make any decisions or expend a lot of effort.
>
> Are we thinking in terms of runtime containers or execution environments? The core build doesn’t matter then. For example, the container work in progress (https://git-wip-us.apache.org/repos/asf/river-container.git) builds with Maven, but uses the River dependencies published in Maven Central.
>
> Are we planning separate modules for Reggie, Mahalo and Outrigger? Those new modules will need a build/integration test system, and we should discuss that. Worth mentioning that so long as the jars go into Maven Central or some other dependency management system, the modules don’t actually need to have the same build tool (although consistency is probably good).
>
> What else are we planning? Chances are, it should go into a different module.
>
> Which brings me to another topic - how should we manage multiple deliverables? Could I suggest the following “deliverable sets”, which would each have different releases?
>
> - Jini Core - Basically what’s currently in jsk-platform.jar
> - Registrar Service Module
> - Transaction Service Module
> - JavaSpaces Service Module
> - note - I’m not sure if Mercury, fiddler, etc are used all that much, but if so, they could have their own modules
> - Jini Application Server (river-container packaged with the infrastructure services)
> - other - Rio? Anything else?
>
> The actual set of modules is open to discussion of course, but I’m thinking we need to support more than one “deliverable”. Not quite “sub projects”, since the governance doesn’t need to be separate, but I think separate source repositories and releases.
>
> In any case, my big suggestion is let’s not take these decisions lightly. There’s no hurry.
>
> Cheers,
>
> Greg.
>
> On Feb 12, 2014, at 5:31 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>
>> On 12-02-14 11:28, Simon IJskes - QCG wrote:
>>> Ok,
>>>
>>> what i have seen is:
>>>
>>> - maven / gradle / ivy
>>> - convention (submodules structure)
>>> - 1 river or submodules (reedy-trasuk)
>>>
>>> Do we need to discuss this further, or do we need a vote on the sub-items.
>>>
>>> Gr. Simon
>>>
>>>
>>
>> in order of pref:
>> - maven
>> - gradle
>> - ivy
>>
>> conventions:
>> +1
>>
>> submodules:
>> +0
>>
>> Gr. Simon
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
[Dicuss] Build Structure
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi all:
I’d just like to sound a quiet note of caution here.
Everyone seems to be in agreement that the current build structure is problematic. After all, it was fundamentally designed around the ‘make’ tool 15 years ago.
However… Altering the build structure and switching to a new tool (Maven, Gradle, Ant/Ivy, etc) will be a _lot_ of work, and we’ll be living with it for a while. Let’s not jump to conclusions without a good discussion.
So let’s start with some reflection…
It’s worth asking “who cares about the build system?” Let’s be clear about something: the vast majority of developers should be using the jars out of Maven Central, or at most running the River build once to build from source. It’s only us, on the River project, who are using the build system. That being the case, perhaps we ought to talk about what we intend to do, before we make any decisions or expend a lot of effort.
Are we thinking in terms of runtime containers or execution environments? The core build doesn’t matter then. For example, the container work in progress (https://git-wip-us.apache.org/repos/asf/river-container.git) builds with Maven, but uses the River dependencies published in Maven Central.
Are we planning separate modules for Reggie, Mahalo and Outrigger? Those new modules will need a build/integration test system, and we should discuss that. Worth mentioning that so long as the jars go into Maven Central or some other dependency management system, the modules don’t actually need to have the same build tool (although consistency is probably good).
What else are we planning? Chances are, it should go into a different module.
Which brings me to another topic - how should we manage multiple deliverables? Could I suggest the following “deliverable sets”, which would each have different releases?
- Jini Core - Basically what’s currently in jsk-platform.jar
- Registrar Service Module
- Transaction Service Module
- JavaSpaces Service Module
- note - I’m not sure if Mercury, fiddler, etc are used all that much, but if so, they could have their own modules
- Jini Application Server (river-container packaged with the infrastructure services)
- other - Rio? Anything else?
The actual set of modules is open to discussion of course, but I’m thinking we need to support more than one “deliverable”. Not quite “sub projects”, since the governance doesn’t need to be separate, but I think separate source repositories and releases.
In any case, my big suggestion is let’s not take these decisions lightly. There’s no hurry.
Cheers,
Greg.
On Feb 12, 2014, at 5:31 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 12-02-14 11:28, Simon IJskes - QCG wrote:
>> Ok,
>>
>> what i have seen is:
>>
>> - maven / gradle / ivy
>> - convention (submodules structure)
>> - 1 river or submodules (reedy-trasuk)
>>
>> Do we need to discuss this further, or do we need a vote on the sub-items.
>>
>> Gr. Simon
>>
>>
>
> in order of pref:
> - maven
> - gradle
> - ivy
>
> conventions:
> +1
>
> submodules:
> +0
>
> Gr. Simon
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
[Dicuss] Build Structure
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi folks - if we could separate out the build structure discussion from the River-432 vote, that’d be great :-)
Greg.
On Feb 12, 2014, at 5:31 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 12-02-14 11:28, Simon IJskes - QCG wrote:
>> Ok,
>>
>> what i have seen is:
>>
>> - maven / gradle / ivy
>> - convention (submodules structure)
>> - 1 river or submodules (reedy-trasuk)
>>
>> Do we need to discuss this further, or do we need a vote on the sub-items.
>>
>> Gr. Simon
>>
>>
>
> in order of pref:
> - maven
> - gradle
> - ivy
>
> conventions:
> +1
>
> submodules:
> +0
>
> Gr. Simon
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 12-02-14 11:28, Simon IJskes - QCG wrote:
> Ok,
>
> what i have seen is:
>
> - maven / gradle / ivy
> - convention (submodules structure)
> - 1 river or submodules (reedy-trasuk)
>
> Do we need to discuss this further, or do we need a vote on the sub-items.
>
> Gr. Simon
>
>
in order of pref:
- maven
- gradle
- ivy
conventions:
+1
submodules:
+0
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
Ok,
what i have seen is:
- maven / gradle / ivy
- convention (submodules structure)
- 1 river or submodules (reedy-trasuk)
Do we need to discuss this further, or do we need a vote on the sub-items.
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Jeff Ramsdale <je...@gmail.com>.
I agree with Dennis--modern dependency management is way more elegant and
less error-prone than classdepandjar.
-j
On Tue, Feb 11, 2014 at 6:35 PM, Dennis Reedy <de...@gmail.com>wrote:
>
>
> Sent from my iPhone
>
> > On Feb 11, 2014, at 8:22 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> >
> >
> > Those recommendations are more applicable to application services than
> those in the core River distribution.
>
> I disagree. River core services exhibit the same exact structure as
> application services, the only difference being that River services are
> produced by the River project.
>
> The referenced conventions mention Maven, but are applicable for other
> project/build tools, including Gradle.
>
> IMO, the most straight forward thing to do is to create a multi-module
> build that creates jars equivalent to the classdepandjar created jars.
>
> Regards
>
> Dennis
>
> > FWIW, however, the core services are already mostly structured this way
> - downloadable classes are all in *-dl.jar files (e.g. reggie-dl.jar,
> mahalo-dl.jar, etc). The only difference is that the core API classes like
> Registrar, JavaSpaces, etc, are in jsk-platform.jar.
> >
> > Now, I think most of us would agree that the ‘classdepandjar’ mechanism
> is a little clunky, so restructuring the build may help with that.
> >
> > I have been using Maven to build applications (e.g. the samples at
> https://github.com/trasukg/river-container-examples). The only thing I
> find slightly irritating is that you end up with a proliferation of Maven
> modules, which equates to a proliferation of Netbeans or Eclipse projects.
> With Maven, that’s unavoidable, because Maven really really wants to have
> only one artifact produced per module. So ‘hello-api’ requires its own
> module, as does ‘hello-service’ (for the implementation code), and
> ‘hello-module’ (the packaging for the container). ‘hello-dl’ would be
> another, if there were a smart proxy. That’s also not specific to Jini
> projects; you get the same thing in JEE6 projects - separate projects for
> the JPA module, EJB module, EJB API, Web module, etc. Other build tools
> may be happier with multiple artifacts from one project. Ant certainly is,
> but of course you drift into the complexities of the current build with
> ‘classDepAndJar’.
> >
> > I think the first step might be to split out the infrastructure services
> like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the
> contents of jsk-platform in the core module. We’ll have to do some
> thinking about how to structure the integration testing for that.
> >
> > Cheers,
> >
> > Greg Trasuk
> >
> >
> >
> >> On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <
> rafal.krupinski@sorcersoft.com> wrote:
> >>
> >> Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
> >>>> On 11-02-14 11:35, Peter wrote:
> >>>>
> >>>> We will need a new build system for java 8, this looks like a step in
> that direction. In reality we need to adopt the build conventions used by
> Rio.
> >>>
> >>> What are these? Maven?
> >>
> >> Not necessarily Maven, although Dennis mentions it.
> >> http://www.rio-project.org/conventions.html#Project_Modules
> >>
> >> It works very well for our River/Rio services.
> >>
> >> Regards
> >> Rafał Krupiński
> >
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Dennis Reedy <de...@gmail.com>.
Sent from my iPhone
> On Feb 11, 2014, at 8:22 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>
> Those recommendations are more applicable to application services than those in the core River distribution.
I disagree. River core services exhibit the same exact structure as application services, the only difference being that River services are produced by the River project.
The referenced conventions mention Maven, but are applicable for other project/build tools, including Gradle.
IMO, the most straight forward thing to do is to create a multi-module build that creates jars equivalent to the classdepandjar created jars.
Regards
Dennis
> FWIW, however, the core services are already mostly structured this way - downloadable classes are all in *-dl.jar files (e.g. reggie-dl.jar, mahalo-dl.jar, etc). The only difference is that the core API classes like Registrar, JavaSpaces, etc, are in jsk-platform.jar.
>
> Now, I think most of us would agree that the ‘classdepandjar’ mechanism is a little clunky, so restructuring the build may help with that.
>
> I have been using Maven to build applications (e.g. the samples at https://github.com/trasukg/river-container-examples). The only thing I find slightly irritating is that you end up with a proliferation of Maven modules, which equates to a proliferation of Netbeans or Eclipse projects. With Maven, that’s unavoidable, because Maven really really wants to have only one artifact produced per module. So ‘hello-api’ requires its own module, as does ‘hello-service’ (for the implementation code), and ‘hello-module’ (the packaging for the container). ‘hello-dl’ would be another, if there were a smart proxy. That’s also not specific to Jini projects; you get the same thing in JEE6 projects - separate projects for the JPA module, EJB module, EJB API, Web module, etc. Other build tools may be happier with multiple artifacts from one project. Ant certainly is, but of course you drift into the complexities of the current build with ‘classDepAndJar’.
>
> I think the first step might be to split out the infrastructure services like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the contents of jsk-platform in the core module. We’ll have to do some thinking about how to structure the integration testing for that.
>
> Cheers,
>
> Greg Trasuk
>
>
>
>> On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>>
>> Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
>>>> On 11-02-14 11:35, Peter wrote:
>>>>
>>>> We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
>>>
>>> What are these? Maven?
>>
>> Not necessarily Maven, although Dennis mentions it.
>> http://www.rio-project.org/conventions.html#Project_Modules
>>
>> It works very well for our River/Rio services.
>>
>> Regards
>> Rafał Krupiński
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Zsolt Kúti <la...@gmail.com>.
On Wed, Feb 12, 2014 at 2:22 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>
> I have been using Maven to build applications (e.g. the samples at
> https://github.com/trasukg/river-container-examples). The only thing I
> find slightly irritating is that you end up with a proliferation of Maven
> modules, which equates to a proliferation of Netbeans or Eclipse projects.
> With Maven, that’s unavoidable, because Maven really really wants to have
> only one artifact produced per module. So ‘hello-api’ requires its own
> module, as does ‘hello-service’ (for the implementation code), and
> ‘hello-module’ (the packaging for the container). ‘hello-dl’ would be
> another, if there were a smart proxy.
Avoiding separation of service api/impl/proxy into modules something to
think about.
> That’s also not specific to Jini projects; you get the same thing in JEE6
> projects - separate projects for the JPA module, EJB module, EJB API, Web
> module, etc. Other build tools may be happier with multiple artifacts from
> one project. Ant certainly is, but of course you drift into the
> complexities of the current build with ‘classDepAndJar’.
>
Gradle is very flexible in this (and in many others too).
>
> I think the first step might be to split out the infrastructure services
> like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the
> contents of jsk-platform in the core module.
>
+1
>
>
>
>
> On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <
> rafal.krupinski@sorcersoft.com> wrote:
>
> > Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
> >> On 11-02-14 11:35, Peter wrote:
> >>
> >>> We will need a new build system for java 8, this looks like a step in
> that direction. In reality we need to adopt the build conventions used by
> Rio.
> >>
> >> What are these? Maven?
> >
> > Not necessarily Maven, although Dennis mentions it.
> > http://www.rio-project.org/conventions.html#Project_Modules
> >
> > It works very well for our River/Rio services.
> >
> > Regards
> > Rafał Krupiński
> >
>
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Jeff Ramsdale <je...@gmail.com>.
Somehow I didn't get Greg's message earlier--just seeing the full text now.
I think the multiple modules resulting in multiple Eclipse projects (for
instance) is a huge strength. Each artifact then has its own classpath and
significantly reduces the possibility of compilation or runtime errors.
Sure there's a little extra complexity in configuration, but that's to help
ensure dependency resolution is correct. As devs we need to be responsible
for the contents of our classpaths and Maven-repository-based tools are a
huge help in that.
Personally I far prefer Maven to Gradle. I do not see the ability to do
custom scripting as an advantage and I find having an XSD schema to work
from reduces errors. Scripting adds a lot of variables (no pun intended)
and could lead to an increased support load. On the other hand, once we
decide to use a dependency-based system over classdepandjar it shouldn't
matter which flavor we use as long as it is compatible with Maven
repository metadata.
-j
On Tue, Feb 11, 2014 at 5:22 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> Those recommendations are more applicable to application services than
> those in the core River distribution. FWIW, however, the core services are
> already mostly structured this way - downloadable classes are all in
> *-dl.jar files (e.g. reggie-dl.jar, mahalo-dl.jar, etc). The only
> difference is that the core API classes like Registrar, JavaSpaces, etc,
> are in jsk-platform.jar.
>
> Now, I think most of us would agree that the 'classdepandjar' mechanism is
> a little clunky, so restructuring the build may help with that.
>
> I have been using Maven to build applications (e.g. the samples at
> https://github.com/trasukg/river-container-examples). The only thing I
> find slightly irritating is that you end up with a proliferation of Maven
> modules, which equates to a proliferation of Netbeans or Eclipse projects.
> With Maven, that's unavoidable, because Maven really really wants to have
> only one artifact produced per module. So 'hello-api' requires its own
> module, as does 'hello-service' (for the implementation code), and
> 'hello-module' (the packaging for the container). 'hello-dl' would be
> another, if there were a smart proxy. That's also not specific to Jini
> projects; you get the same thing in JEE6 projects - separate projects for
> the JPA module, EJB module, EJB API, Web module, etc. Other build tools
> may be happier with multiple artifacts from one project. Ant certainly is,
> but of course you drift into the complexities of the current build with
> 'classDepAndJar'.
>
> I think the first step might be to split out the infrastructure services
> like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the
> contents of jsk-platform in the core module. We'll have to do some
> thinking about how to structure the integration testing for that.
>
> Cheers,
>
> Greg Trasuk
>
>
>
> On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <
> rafal.krupinski@sorcersoft.com> wrote:
>
> > Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
> >> On 11-02-14 11:35, Peter wrote:
> >>
> >>> We will need a new build system for java 8, this looks like a step in
> that direction. In reality we need to adopt the build conventions used by
> Rio.
> >>
> >> What are these? Maven?
> >
> > Not necessarily Maven, although Dennis mentions it.
> > http://www.rio-project.org/conventions.html#Project_Modules
> >
> > It works very well for our River/Rio services.
> >
> > Regards
> > Rafał Krupiński
> >
>
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Greg Trasuk <tr...@stratuscom.com>.
Those recommendations are more applicable to application services than those in the core River distribution. FWIW, however, the core services are already mostly structured this way - downloadable classes are all in *-dl.jar files (e.g. reggie-dl.jar, mahalo-dl.jar, etc). The only difference is that the core API classes like Registrar, JavaSpaces, etc, are in jsk-platform.jar.
Now, I think most of us would agree that the ‘classdepandjar’ mechanism is a little clunky, so restructuring the build may help with that.
I have been using Maven to build applications (e.g. the samples at https://github.com/trasukg/river-container-examples). The only thing I find slightly irritating is that you end up with a proliferation of Maven modules, which equates to a proliferation of Netbeans or Eclipse projects. With Maven, that’s unavoidable, because Maven really really wants to have only one artifact produced per module. So ‘hello-api’ requires its own module, as does ‘hello-service’ (for the implementation code), and ‘hello-module’ (the packaging for the container). ‘hello-dl’ would be another, if there were a smart proxy. That’s also not specific to Jini projects; you get the same thing in JEE6 projects - separate projects for the JPA module, EJB module, EJB API, Web module, etc. Other build tools may be happier with multiple artifacts from one project. Ant certainly is, but of course you drift into the complexities of the current build with ‘classDepAndJar’.
I think the first step might be to split out the infrastructure services like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the contents of jsk-platform in the core module. We’ll have to do some thinking about how to structure the integration testing for that.
Cheers,
Greg Trasuk
On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
>> On 11-02-14 11:35, Peter wrote:
>>
>>> We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
>>
>> What are these? Maven?
>
> Not necessarily Maven, although Dennis mentions it.
> http://www.rio-project.org/conventions.html#Project_Modules
>
> It works very well for our River/Rio services.
>
> Regards
> Rafał Krupiński
>
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
> On 11-02-14 11:35, Peter wrote:
>
> > We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
>
> What are these? Maven?
Not necessarily Maven, although Dennis mentions it.
http://www.rio-project.org/conventions.html#Project_Modules
It works very well for our River/Rio services.
Regards
Rafał Krupiński
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Zsolt Kúti <la...@gmail.com>.
On Wed, Feb 12, 2014 at 8:08 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> http://www.rio-project.org/tutorial/service/service-intro.html
>
> Gradle and Ivy (if you prefer ant) are also possibilities for dependency
> management and if Ivy was already being used then it would be more likely
> to be the build tool of choice. However Gradle is attractive as it uses
> Groovy and since Dennis donated a Groovy Configuration, that might make
> testing easier.
>
I would vote on gradle. This offers the most on the long run.
Cant promise anything in short term but would be interested in
participating if we are to move that direction.
Zsolt
[Dicuss] Build Structure
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Feb 12, 2014, at 2:08 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
Not that I have any strong opinions on Maven vs Gradle, but aren’t you conflating build system with Configuration provider? I don’t see how the presence of a GroovyConfiguration provider has any influence on whether Gradle, Maven, or Ant should be used for the build system.
Greg Trasuk
>
>
> Gradle and Ivy (if you prefer ant) are also possibilities for dependency management and if Ivy was already being used then it would be more likely to be the build tool of choice. However Gradle is attractive as it uses Groovy and since Dennis donated a Groovy Configuration, that might make testing easier.
>
> Just throwing in my 20cents for disucssion.
>
> Regards,
>
> Peter.
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 12/02/2014 12:59 AM, Simon IJskes - QCG wrote:
> On 11-02-14 11:35, Peter wrote:
>
>> We will need a new build system for java 8, this looks like a step in
>> that direction. In reality we need to adopt the build conventions
>> used by Rio.
>
> What are these? Maven?
>
> Gr. Simon
>
http://www.rio-project.org/tutorial/service/service-intro.html
Gradle and Ivy (if you prefer ant) are also possibilities for dependency
management and if Ivy was already being used then it would be more
likely to be the build tool of choice. However Gradle is attractive as
it uses Groovy and since Dennis donated a Groovy Configuration, that
might make testing easier.
Just throwing in my 20cents for disucssion.
Regards,
Peter.
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-02-14 11:35, Peter wrote:
> We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
What are these? Maven?
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Posted by Peter <ji...@zeus.net.au>.
+1 Peter.
Note that the current build system does not support java 8.
Maintaining a build system is a significant burden ( I know I had to implement Java 5 support).
We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio.
Regards,
Peter.
----- Original message -----
>
> As discussion has settled somewhat, I would like to call another vote to
> accept the latest patch described in
> https://issues.apache.org/jira/browse/RIVER-432
>
> The patch removes the archived jar files for Velocity and ASM and
> replaces them with Apache Ivy scripts that download the jars from Maven
> Central the first time a build is done. From then on, the jar files are
> in Ivy’s repository (for more info, see http://ant.apache.org/ivy).
>
> Voting will remain open at least until 2000 UTC Feb 13, 2014.
>
> Cheers,
>
> Greg.
>
>
> On Jan 3, 2014, at 12:57 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> >
> > On Jan 3, 2014, at 5:25 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> >
> > > In order to gain some time to discuss this first i will vote -1.
> > >
> > > First, we decided to NOT remove velocity builder.
> >
> > When I read the email chain, my impression was that we wanted to
> > remove it (to quote you Sim, “To be honest, I hate it”), but there was
> > a dependency on it in the ‘extras’ folder that was added in the trunk
> > branch. As there is no ‘extras’ in the 2.2 branch, and that is what
> > this patch applies to, I thought it was fair to remove
> > VelocityConfigurationBuilder from the 2.2 branch. Perhaps we should
> > revisit the ConfigurationBuilder approach in another thread. For now
> > I’ll spin another patch that doesn’t remove
> > VelocityConfigurationBuilder.
> >
> > >
> > > Second, no need to remove the jars as specified in your own comments
> > > on RIVER-432.
> > >
> > > Pulling in external jars at compile time, shall we start here?
> > >
> > > They are already in the svn. They are already in the build scripts.
> > > What does this patch fix? No legal problems?
> > >
> >
> > Apache policy is somewhat unclear on this point. One needs to examine
> > the mailing lists for clues on what we should really do. I will argue
> > that:
> >
> > 1 - The fundamental distribution model of Apache is source code, not
> > binaries. 2 - Distributing binaries is tolerated but not encouraged.
> > Since the svn repository can be seen as a distribution point, binaries
> > in svn are also tolerated but not encouraged. 3 - Downloading
> > dependency binaries at build time is technologically easy, provides
> > the same guarantees as putting them in cvs, and avoids the question of
> > effectively distributing someone else’s code.
> >
> > All these together suggest that although we’re technically OK to put
> > dependency jars in a “-deps” package (note that the status quo _is_
> > unacceptable - at the very least, we need to restructure the
> > dependencies into a “-deps” binary package), there is some policy
> > uncertainty which we avoid totally by having dependencies downloaded
> > from a known-good source at build time.
> >
> > Let’s examine these points:
> >
> > 1 - The fundamental distribution model of Apache is source code, not
> > binaries. Apache began with httpd. Back in those days, “Open Source”
> > software was distributed in source form only, simply because it was
> > mostly intended for Unix systems (then later Linux). I recall the
> > first release of Perl coming down as a ten-part uunet news message.
> > Part of this distribution model was practical necessity - System
> > differences made it necessary to compile your software on the hardware
> > it was going to run on. Part of it was open-source philosophy.
> > Having the source code meant that you could take a look at it and
> > verify that it wasn’t hazardous to your operations.
> >
> > In any case, the way we use to use open source software was
> > (“./configure; make; make install”). If the software had
> > dependencies, you built them from source, for the same reasons.
> >
> > Now, as time has gone on, we’ve gotten used to having the JVM as a
> > common runtime, and jar files as a common binary distribution medium.
> > But the Apache Foundation’s mandate is to produce open source software
> > that is freely usable under the Apache License. That means source
> > code is at the heart of Apache, despite the rest of the world’s
> > comfort with binaries. Hence Roy’s statements in (1):
> >
> > > Class files are not open source. Jar files filled with class files
> > > are not open source. The fact that they are derived from open source
> > > is applicable only to what we allow projects to be dependent upon,
> > > not what we vote on as a release package. Release votes are on
> > > verified open source artifacts. Binary packages are separate from
> > > source packages. One cannot vote to approve a release containing a
> > > mix of source and binary code because the binary is not open source
> > > and cannot be verified to be safe for release (even if it was
> > > derived from open source).
> > >
> > > I thought that was frigging obvious. Why do I need to write
> > > documentation to explain something that is fundamental to the open
> > > source definition?
> > He’s talking about binary packages, not jar files in svn, but I read
> > that (and many other emails) as a distaste for binary distributions.
> >
> > In fact, if you look at Apache httpd’s download page, it doesn’t
> > appear that the Apache project publishes any Unix or Linux binaries.
> > They leave that to other organizations.
> >
> > 2 - Distributing binaries is tolerated but not encouraged. Since the
> > svn repository can be seen as a distribution point, binaries in svn
> > are also tolerated but not encouraged.
> >
> > It’s hard to find a single reference that encapsulates this outlook,
> > but that’s the impression I get from reading the various mailing
> > lists. For instance, Sam Ruby says (2):
> > > IMO, our projects release source. So, our projects should not
> > > maintain object/binary artifacts in their svn release tree,
> > > regardless of license (category a or b).
> > There is some debate on whether the svn tree should be considered a
> > distribution point. Incubator releases are regularly called out for
> > not having “NOTICE” and “RELEASE” files at all reasonable checkout
> > points in svn. [LEGAL-26]
> > (https://issues.apache.org/jira/browse/LEGAL-26) concerns this and
> > remains unresolved.
> >
> > Doug Cutting (3) says:
> > > On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
> > > <st...@gmail.com> wrote:
> > > > * Source control is not an Apache distribution and hence we do not
> > > > need to have LICENSE and NOTICE files in source control, it can be
> > > > a nice convenience, but there is no *requirement*.
> > >
> > > I think perhaps you're looking for clear lines where things are
> > > actually a bit fuzzy. Certainly releases are official distributions
> > > and need LICENSE and NOTICE files. That line is clear. On the other
> > > hand, we try to discourage folks from thinking that source control is
> > > a distribution. Rather we wish it to be considered our shared
> > > workspace, containing works in progress, not yet always ready for
> > > distribution to folks outside the foundation. But, since we work in
> > > public, folks from outside the foundation can see our shared
> > > workspace and might occasionally mistake it for an official
> > > distribution. We'd like them to still see a LICENSE and NOTICE
> > > file. So it's not a hard-and-fast requirement that every tree that
> > > can possibly be checked out have a LICENSE and NOTICE file at its
> > > root, but it's a good practice for those trees that are likely to be
> > > checked out have them, so that folks who might consume them are well
> > > informed.
> > Again, he’s not talking directly about jar files in svn, however I
> > think his statement that “since we work in public, folks from outside
> > the foundation can see our shared workspace and might occasionally
> > mistake it for an official distribution” applies here. Fundamentally,
> > the decision on how and where to distribute ‘velocity.jar’ rightly
> > belongs with the Velocity group and I don’t think we ought to
> > redistribute it.
> >
> > 3 - Downloading dependency binaries at build time is technologically
> > easy, provides the same guarantees as putting them in cvs, and avoids
> > the question of effectively distributing someone else’s code.
> >
> > There doesn’t seem to be clear policy in the ASF on this, as evidenced
> > by the frequent debates on it, and the lack of documentation. I’ve
> > tried to lay out an argument that having jars in svn is not encouraged
> > by the ASF (really, it’s not in line with the ASF’s charter), even if
> > it isn’t disallowed. You may disagree, and I won’t claim I’ve made a
> > strong argument, simply because the policy isn’t clear. So instead of
> > going through arguments that amount to differences of opinion on
> > Apache policy, let’s use a technological solution that is simple,
> > common, and avoids the question altogether, by automatically
> > downloading the dependencies at build time.
> >
> > Projects that use Maven do this automatic download as standard
> > practice (that’s what Maven does, and that’s what the Maven Central
> > infrastructure is there to support). We don’t use Maven, which is
> > fine (our customers have asked us to make our binaries available in
> > Maven Central, and we’ve done that). Apache Ivy is a popular add-on
> > to Apache Ant that provides similar dependency resolution to an
> > Ant-based build.
> >
> > I was a little surprised how easy it was to persuade Ivy to get the
> > required dependencies at build time. The “ivy.xml” file is 39 lines
> > including the ASL header (which by the way I forgot to include in the
> > patch - I’ll fix that). There are about 50 lines added to ‘build.xml’
> > to download Ivy and then download the required jar files
> >
> > So, given that the status-quo seems to be unacceptable (Roy talks
> > about not having jar files in the open-source trees, only in “-deps”
> > and “tools” trees), we have two options:
> >
> > (a) - restructure the svn repository and the build to allow a separate
> > “-deps” distribution. This wouldn’t affect our binary distributions
> > (note that I’m no longer using the term “binary release”), but to
> > build from source, a user would have to download a separate archive,
> > unpack it, and then copy those files into the directory that was
> > unpacked from the source release. This option effectively still has
> > us distributing dependent binaries, which is not the goal of the ASF,
> > just with a disclaimer that says “this isn’t an ASF release, its just
> > a binary distribution put together by a committer for your
> > convenience, so don’t feel you should trust it too much”.
> >
> > (b) - use Ivy to get the jars from Maven Central automatically as part
> > of the build.
> >
> > I think (b) is the option that causes the least hassle for our
> > downstream consumers, and not much hassle for us.
> >
> >
> > > Pulling external jars at compile time also makes it more difficult
> > > to certify the software. In order to certify the software you need
> > > to establish baseline that will be garanteed the same, even if you
> > > pull it from the archive 10 years later.
> >
> > As I said above, Apache’s focus is creating software that can be built
> > from source, not distributing binaries (note that QCG or another
> > company might have a different focus, and is perfectly able to
> > distribute binaries under the Apache license). I think a reasonably
> > prudent user would ask “How can I trust the ‘velocity.jar’ that’s
> > included in this binary?” And the answer would be either “because I
> > built it from source and installed it in my corporate repository”
> > (very cautious, but not unheard-of) or “It was published by the
> > Velocity group to a trusted repository, Maven Central” (more common).
> >
> > If you look in the “ivy.xml” file you’ll see that the dependencies are
> > specified using Maven-style “group-artifact-version” coordinates. Old
> > versions are maintained in Maven Central forever. I suppose it’s
> > possible that a publisher could convince Maven Central to remove a
> > version for some reason (security or licensing problems perhaps), but
> > then, would we want to be distributing that version in a “-deps”
> > package?
> >
> > I agree that it’s not enough to just say “you need to download
> > such-and-such jar”, hence the automatic download managed by “Ivy” from
> > Maven Central.
> >
> > > It is not a high level project that builds on several frameworks. It
> > > is a lowlevel system library. The stuff below the stack is minimal.
> > > The number of jars we use is limited. Why bother?
> > >
> >
> > In the currently released branches, the dependencies are limited to
> > ASM and Velocity. Looking forward to the trunk branch and the
> > qa_refactor branch, the number of external dependencies seem to be
> > increasing (IMO I don’t like that, because I also view River as a low
> > level system library, but I’m only one PMC member). We need to get in
> > front of the problem before we start distributing large numbers of
> > dependencies.
> >
> > This point rolls in with the general question of jar files in version
> > control. I was always taught that version control was for source
> > code, and putting binaries into version control was a bad idea. In
> > addition, there are practical problems - with older systems like cvs,
> > even doing an update or commit effectively downloads the binaries,
> > which slows things down if there are large binary files. On newer
> > distributed version control systems like git or Mercurial, the entire
> > repository, including all versions of binary artifacts, comes down
> > with the project checkout. Currently, we have one version of
> > relatively few jar files in our repository, so it’s not a major issue.
> > But it gets worse as time goes on. So I suggest we work out the
> > technology now to avoid the problem.
> >
> > > Gr. Simon
> > >
> >
> > Thanks for the questions, Sim. I hope you’ll come around to removing
> > your ‘-1’.
> >
> > Cheers,
> >
> > Greg
> >
> > Footnotes
> > ——————
> >
> > (1) - Roy Fielding - http://s.apache.org/roy-binary-deps-1
> > (2) - Sam Ruby - http://s.apache.org/r5
> > (3) - Doug Cutting - http://s.apache.org/GNP
> >
> > > On 02-01-14 18:22, Greg Trasuk wrote:
> > > >
> > > > Hello all:
> > > >
> > > > Please have a look at the patch mentioned below and cast a vote on
> > > > it.
> > > >
> > > > The main idea is to remove the dependency jar files from the
> > > > source distribution. As a side effect of using Ivy, it becomes
> > > > reasonable to remove them from the svn archive as well. Also, the
> > > > Velocity dependency was there to support the
> > > > VelocityConfigurationBuilder. We had discussed removing that
> > > > component, so rather than move that dependency to Ivy, I’ve
> > > > removed VelocityConfigurationBuilder.
> > > >
> > > > It’s arguable whether the VelocityConfigurationBuider was part of
> > > > the official Jini API (I see it as a utility, not API), so I don’t
> > > > think this commit actually requires a vote. However, it does seem
> > > > like a significant change to the build process that ought to be
> > > > reviewed. So I propose to treat this as a “lazy consensus” vote,
> > > > and will commit the change to the 2.2 branch if there are no
> > > > objections in 72 hours (i.e. 1730UTC 20140105).
> > > >
> > > > At the same time, based on discussions over on
> > > > general@incubator.apache.org, I’ll withdraw my assertion that we
> > > > can’t have jars in svn. Those interested may want to check out
> > > > the thread at
> > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E
> > > >
> > > > Cheers,
> > > >
> > > > Greg.
> > > >
> > > > On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA) <ji...@apache.org>
> > > > wrote:
> > > >
> > > > >
> > > > > [
> > > > > https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > > > > ]
> > > > >
> > > > > Greg Trasuk updated RIVER-432:
> > > > > ------------------------------
> > > > >
> > > > > Attachment: river-2_2_remove_jars.diff
> > > > >
> > > > > The attached patch for the 2.2 branch does the following:
> > > > > - removes the 'asm' directory and 'tests/lib' directories which
> > > > > currently contain the asm library, mockito, and junit jars. -
> > > > > Modifies 'build.xml', 'common.xml', and adds 'ivy.xml' so that
> > > > > the Apache Ivy ant plugin is downloaded at build time, and then
> > > > > used to retrieve the libraries mentioned above from Maven
> > > > > Central. This removes the need to have the jar files in svn. -
> > > > > Removes (as per discussion
> > > > > http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E)
> > > > > the VelocityConfigBuilder, and associated Velocity jars. Note
> > > > > that the 'extras' folder is not present in the 2.2 branch, so
> > > > > Sim's last comments in the thread do not apply.
> > > > >
> > > > > > Jar files in svn and src distributions
> > > > > > --------------------------------------
> > > > > >
> > > > > > Key: RIVER-432
> > > > > > URL: https://issues.apache.org/jira/browse/RIVER-432
> > > > > > Project: River
> > > > > > Issue Type: Bug
> > > > > > Reporter: Greg Trasuk
> > > > > > Attachments: river-2_2_remove_jars.diff
> > > > > >
> > > > > >
> > > > > > Recent traffic on the incubator lists has pointed out that
> > > > > > including jar files for dependencies in the subversion
> > > > > > repository and the source distributions is against Apache
> > > > > > policy. In River, the following libraries appear in the
> > > > > > Subversion repository and the source distributions (these are
> > > > > > from trunk, a smaller set appear in the 2.2 branch):
> > > > > > animal-sniffer asm bouncy-castle dnsjava high-scale-lib
> > > > > > rc-libs
> > > > > > velocity
> > > > > > They all have to go. What are we using them for? As I
> > > > > > understand it, we were going to remove the
> > > > > > VelocityConfigurationBuilder, so that's not a problem. Some
> > > > > > of the others are available from Maven Central, so we can get
> > > > > > them at build time using Ivy or another build tool. Which
> > > > > > ones are actually required? And where did they come from?
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > This message was sent by Atlassian JIRA
> > > > > (v6.1.5#6160)
> > > >
> > >
> > >
> > > --
> > > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> > > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
> >
>