JBIDE-12821 #134
JBIDE-12821 #134
Conversation
| * @version $Id$ | ||
| */ | ||
| public class StringUtils | ||
| { |
There was a problem hiding this comment.
can't you use commons-lang's StringUtils class instead in your imports?
There was a problem hiding this comment.
Will look into this idea.
|
I understood it as you've made this work with eclipse VFS file system - I don't see that. I see you made it possible to abstract the traversal of the filesystem but that this filesystem must map to java.io.File's elements. Thus it is not really working with the Virtual file system (i.e. how would this thing here work with linked resources in eclipse workspace ?) And just in general please avoid non-informative commits like:
Squash that and actually explain/document what the commit does. Above is not relevant for anyone but you working locally - in a review case and going back to find the changes/track down why something happened those commit messages will just be noise. |
The project archives client / subclass used a FileWrapper, which is part of API and is also part of method signatures and so cannot be changed. You can see it here: The lines you'll be looking at are: protected File[] list2workspace(File file) , which is where it uses the VFS to return the list of children for any given workspace File. The strange thing here is that archives.core ALSO does not know about eclipse classes except for very very few, due to the original structure 6 years ago, so they also cannot traverse the IResource model directly. Strangely enough, I could import them into the file (they are recognized as on the classpath) but it breaks the very old ant use-case and requires more jars being on teh classpath when running standalone. So the structure of project archives is super old and somewhat fragile. It is very easy to accidentally import eclipse classes and then have the ant usecase broken.
Linked resources do work. They get sent to a class named WorkspaceVFS: |
|
|
||
|
|
||
| /** | ||
| * Get a list of child files from this file. |
There was a problem hiding this comment.
"Get a list of child files or directories", right?
|
running all tests from jbosstools-server/archives/tests shows 0% coverage for new plugin |
|
It seems very strange to me that running the tests gets 0% coverage. The test suite very explicitly adds 2 new tests which I have personally seen run. Can you please outline your methodology? I find it very difficult to imagine these two tests have 0% coverage, and it's clear in the PR that the two tests have been added, and if you read the (fairly simple) tests, they clearly import, instantiate, and use, the classes in the new plugin. |
|
Coverage problem is related to parent pom and archives.scanner properties, I'll submit PR with temporary fix for your branch |
|
See in robstryker#2 how to fix coverage report for archives tests |
|
Would be good to have origin reference for every 3rd party class copy and enhancements/changes description |
as converting existing clients to use the new bundle JBIDE-12821 adding 2 tests JBIDE-12821 - rewrote the scanners to use generics and interfaces JBIDE-12821 - removed unnecessary .asf packages and split things into simply scanner and scanner.internal JBIDE-12821 - removed unnecessary .asf packages and split things into simply scanner and scanner.internal. Apparently the files did not 'move' properly JBIDE-12821 - bad manifest.mf line, erroneous @OverRide line JBIDE-12821 - adding new bundle for scanners, and new feature, and updating existing features to ensure its present JBIDE-12821 - renaming package since it did not match bundle name JBIDE-12821 - fixed failing unit test and small problems with feature version etc JBIDE-12821 - updating javadoc and removing from sysouts from tests JBIDE-12821 - fixing version to match newest archives versions JBIDE-12821 updating manifest.mf for version ranges JBIDE-12821 somehow missed adding the entire source folder JBIDE-12821 - reverting changes to org.jboss.ide.eclipse.archives.core.asf.DirectoryScanner to maintain api compatability during deprecation. JBIDE-12821 - copyright date updates JBIDE-12821 renamed one method which referenced file instead of node, updated javadoc [JBIDE-12821] change code coverage configuration for archives module new plugin included in coverage report: org.jboss.tools.archives.scanner JBIDE-12821 - removal of stringutils as unnecessary JBIDE-12821 - further removal of all unneeded methods to ensure the smallest plugin possible JBIDE-12821 - modifying the code in DirectoryScannerFactory to ensure the smallest API breakage possible. Replacing all moved or missing method signatures JBIDE-12821 - added an api compatability filter; usage scan reveals no outside consumers
Adds regexp support for both project archives and astools publishing via the component model.