Distributing separated jar files as per build.xml.

[wilx]

The older versions of BSH seemed to have been available in split form in multiple artifacts like bsh-core, bsh, etc. But version 2.0b6 in group org.apache-extras.beanshell seems to be only available as whole bsh artifact even though the releases page contains individual JARs. Is this intentional?

[nickl-]

That was before my time... we can leave this issue open for a while, maybe someone who knows about the intentions will respond but you shouldn't hold your breath.

Current development is focused on the development branch merge-fork-beanshell2 and completing the road map to the next release.

If you want to get involved with the new discussions #17 questions what group id we should use and #81 pertains to the next release. If the multiple releases is a requirement would you please mention it at #81.

With all the fixes already applied and the storm of outstanding issues that still need to be addressed I cannot in good conscience suggest anyone should be using the old releases.

[wilx]

I do not want to use the old releases either, that is why I am curious about this, we are trying to update to fix the one CVE. :) But I would rather have 1:1 mapping of the dependencies from old to new, if it were possible at all.

[wilx]

I am closing this. I actually took a look at the source and tried to modularize it using Maven but the previously existing Maven artefacts are not reasonably independent or hierarchically dependent.

[nickl-]

@wiix which CVE? Has this been resolved?

I think the previous bundles were created with the ant build script, there might be some work required to replicate the same with the new maven build.

[wilx]

@nickl- commented on Aug 12, 2018, 7:06 PM GMT+2:

@wiix which CVE? Has this been resolved?

I think the previous bundles were created with the ant build script, there might be some work required to replicate the same with the new maven build.

I tried. But the classes in the original JARs depend on each other, they do not form tree hierarchy. That is hard to do in Maven.

[nickl-]

I haven't looked myself yet...there's just so much else that needs doing. =/

We'll get there eventually...

Tx for the feedback!

[nickl-]

Even though there are other ways to accomplish this, some examples available on this page by sonatype, but the preferred maven approach would be splitting the project into separate modules. Each module will be capable of producing its own artefacts equivalent to what the ant build produced in the past.

I have started with a proof of concept on the modularize branch and currently have the following projects defined. Listing the maven artefact ids and names:

bsh-project  - BeanShell Project
├──  bsh - BeanShell Assembly
├──  bsh-core - BeanShell Core
├──  bsh-test - BeanShell Test

The bsh-project is considered the parent pom which now contains all the project specific identifiers like description, url, license, developers, scm, issue and distribution management which can be inherited by the modules. It also provides the project wide properties and definitions for plugin and dependency management.

The bsh module is equivalent to the current project artifactId in what it will produce. It is an empty assembly only module, that contains no source code whatsoever, which will have all the other source code modules as dependencies (currently only bsh-core) and is tasked with producing the combined single jar file distribution artefact eg. bsh-3.0.0.jar.

The bsh-core module currently consists of all the source code but no unit tests and will be further split into the separate modules. It has now and will always have no module dependencies and is tasked to produce the artefact bsh-core-3.0.0.jar.

The bsh-test module contains the unit tests for the entire project and has the bsh module as dependency. It does not produce any distributed artefacts.

[nickl-]

The initial proof of concept works as expected except for code coverage. When running mvn install the first module bsh-core gets compiled with all testing phases disabled. Then the bsh module assembles the classes of bsh-core and produces the desired executable jar artefact. From tests done with a mockup the same concept combined the classes from separate modules so this will work as expected. The bsh-test module has all the default jar, compile, resource and install phases disabled and successfully completes running all the tests against the assembled module (see travis build # 320).

I cannot get jacocco to produce any reports, it is supposed to work for separate source modules and a test only module using report aggregate but it only produces an empty report for me see 2b07f8f .

I am thinking we remove code coverage for now until we can try and revisit this again or find another solution. There is more value in producing the separate artefacts IMO then having the luxury of code coverage reports. At least we have reached 70% coverage for the development roadmap. Any suggestions?

[nickl-]

Going forward we need to separate the bsh-core module to produce the following additional modules.

• [x] bsh-commands
• [ ] bsh-classpath
• [ ] bsh-reflect
• [ ] bsh-util
• [ ] bsh-bsf
• [ ] bsh-engine
• [ ] bsh-classgen
• [ ] bsh-servlet

If you want to assist please use git mv as your firs commit (see 451388a) when moving the files so that we can retain the history and replay a rebase of any changes that occur on master in the interim.

[nickl-]

Invite for comments: @pgiffuni @mjwall @dleuck @mjwall @patniemeyer @pejobo @simonetripodi @stain @wiix @opeongo @drosenbauer @stefanofornari

[drosenbauer]

Let's just make sure it gets documented which features are in which sub-project, particularly the ones with sort of generic names like "util". Which would I need for a basic embedded invocation from Java, for example?

[nickl-]

@drosenbauer thank you for your input

Let's just make sure it gets documented which features are in which sub-project,

This follows the conventions used previously as configured in the legacy (non functioning) ant build script but you are correct I don't think I have seen any documentation explaining their contents or uses.

[nickl-]

Found an explanation of the distributions: http://beanshell.org/download.html