Did not works for most Java projects about sweep HOT 7 CLOSED

Also,

To do the job, the target [...] is to identify distinct project patterns and to handle at least the more popular ones by default.

This is the goal. But I don't know all the popular build tools for every programming language, so I'll need a little help with that part 😄

from sweep.

maven projects imply a target folder that can be cleaned by Sweep but without that, the compiled binaries location is less predictable because is IDE related (Eclipse use bin folder by default for example).

Probably IDE specific config file need to be detected (.project for Eclipse based, {project}.iml for Jebrains products) and parsed. For Eclipse, .project containing <nature>org.eclipse.jdt.core.javanature</nature> and .classpath with <classpathentry kind="output" path="bin"/> to confirm output folder to clean.

Maven projects are very common in java world (more than gradle actually implemented or using only IDE build), and Sweep actually does not handle maven. I propose this pull request to handle maven : #20

from sweep.

Regarding "Maven is not a Java Standard", Jetbrains 2020 survey got these results : https://www.jetbrains.com/lp/devecosystem-2020/java/
Despite the popularity of Maven (71%) and Gradle (48%), 9% of Java developers still prefer Ant for building their projects.

So maven must be the basic to handle for most of java projects. Nowadays, a team can work with different IDE so more rely to build tools like maven / gradle instead of IDE and not commit in source control the IDE settings.

from sweep.

There is no standard tools but just more or less popular ones. To do the job, the target is not to know which IDE or build tool is the most popular (tip: the answer is Eclipse/Maven). It is to identify distinct project patterns and to handle at least the more popular ones by default. Ideally, the tool must be extensible and it should allow the users to add/share new (global) patterns.

I work on multiple projects for many companies, so I have many projects on my computer with a lot of Java. For information, if I do some Java build tools usage statistics ( with find command) on my local disk, I get (total projects counts):

• ANT: 841
• Maven: 668
• Gradle: 4

My few personal projects are not included. Personally, for Java projects, I use exclusively Gradle and NetBeans...

After testing sweep, I was very disappointed to discover the content of detect_cleanable_project.rs. The most deceptive was to see that project detection patterns are hardcoded!

I think that projects patterns must be configurable and declarative, like:

gradle: build.gradle > build/ .gradle/
maven:  pom.xml > target/
eclipse: .project .classpath > bin/
node.js: package.json > node_modules/ .cache/
rust: Cargo.toml > target/

Ideally, the user should be able to:

• Configure the default applicable pattern list (all are applicable if not configured)

• Add his own patterns.

  • For example, in cases like ANT, there is an established standard for the build files, but there are no strict rules for the folder's hierarchy and names. Custom patterns can be required in this case.

• The swpfile should allow to define or redefine new local patterns for the current tree, and eventually activate or disable global patterns ( example configuration lines: +gradle or -maven )

I know that it's quite (too) different from the current implementation, but it is what I have initially expected from the project presentation: being able to sweep "my" projects storage space.

from sweep.

The default discovery rules are indeed incredibly simple and limited. They are just modeled after my own usage patterns and I don't really write much Java, so I don't know all of the directories that need to be cleaned. I simply implemented a check for pom.xml because my 3 Java projects at the time had that and it seemed like a tool many Java developers used.

Feel free to open PRs to add more accurate rules and support a wider range of projects. I'd love to expand the usefulness of Sweep to more people!

If you have a project with a custom structure (i.e. not something that is standardised by a well-known build tool), you can always create a swpfile where you can define which paths should be cleaned for that project specifically.

I think that projects patterns must be configurable and declarative

I think the task of configuring cleanable project paths is covered pretty well by the swpfile as it is right now, and I quite like that it resembles an .ignore file because that's a well-known format. So I don't know if we need to change the syntax that much. Especially since they are per-project, so they don't need to be that 'generic'.

If you wre talking about the default rules, then I don't think that warrants an entire custom DSL. The code in detect_cleanable_paths.rs should be fairly easy to understand, so most developers should be able to add to it. If not, I'm open to improvements and clarifications in the code (which goes for the entire codebase, but especially for that file cause I want to make it easy for even non-Rust developers to add rules).

The swpfile should allow to define or redefine new local patterns for the current tree, and eventually activate or disable global patterns ( example configuration lines: +gradle or -maven )

That is a really cool idea! It would mean that we'd have to be careful about default paths though, if you add e.g. +gradle and we add a default cleanup directory to the gradle rule, the user may not expect this additional directory to be cleaned after an update. This is one of the reasons that I recommend using a swpfile by default (all of my projects have a swpfile, along with the gitignore and editorconfig and any other dotfiles the project needs). I'd love to hear some more fleshed out ideas/proposals for this syntax.

from sweep.

Probably IDE specific config file need to be detected (.project for Eclipse based, {project}.iml for Jebrains products) and parsed. For Eclipse, .project containing org.eclipse.jdt.core.javanature and .classpath with to confirm output folder to clean.

I considered this when I initially worked on this tool, but the directories that are ignored in your IDE vs the ones that you actually want to delete aren't always the same. So the IDE-specific config can't be the only source of truth. And if you're going to keep a swpfile anyways, you could easily add in a couple extra paths. Additionally, writing code to parse the configuration files for every IDE out there (and keeping it up-to-date whenever those IDEs update their config format) would be a major time investment that I'm not able to make. So I decided to go for simple and easily configurable per project.

from sweep.

There haven't been any responses in the last 2 months so I'm gonna go ahead and close this issue.

As we established, the default project detection rules are far from perfect. So I would love some contributions to help improve them. If you want to help out with that, simply open a new issue for the use case(s) you'd like to cover.

from sweep.