Refactor filter classes into another package?

[douglm]

Is your feature request related to a problem? Please describe.
I'm seeing a lot more filter classes appear in the dev code and wonder if the whole filtering code ought to be packaged separately.
I think this would help make for a lighter weight ical4j. Personally I suspect I'll not use the filter classes at all.
The only dependency I found in the main code was in ComponentGroup which could really belong in a filter package

Describe the solution you'd like
Move all the filter classes into a new package - along with the above class

Describe alternatives you've considered
None really

Additional context
In general I'd like to keep ical4j-core tightly focused on representing iCalendar data. At least within the implementations I've worked on the parsing and model classes are pretty much all I use. So I guess I'd really liek to see a package without the agent and transform classes as well.

[benfortuna]

Hi Mike,

Yes it makes sense to deconstruct into smaller libraries, especially with the module support in Java 9+.

I'm thinking of a slightly different approach to previous ical4j extension libraries, in that I will explore the use of subprojects within the same ical4j repository. This will be easier to manage releases, and allow for easier refinement of ical4j "modules" over time.

So initially we might have a refactor of the ical4j library with following subprojects:

• core
• filter
• transform

I will probably wait until ical4j 4 is released, and then see if it can be backported to 3.x.

[douglm]

That sounds good. 4 is probably the place to do that.