Bug 102711 - allow source groups with non-existing rootFolder
allow source groups with non-existing rootFolder
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
6.x
All All
: P3 (vote)
: 6.x
Assigned To: Milos Kleint
issues@projects
: API, API_REVIEW_FAST
Depends on: 195253
Blocks: 97170 96266 143633
  Show dependency treegraph
 
Reported: 2007-04-27 09:50 UTC by Milos Kleint
Modified: 2011-02-09 21:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
initial diff (9.59 KB, patch)
2007-05-30 08:05 UTC, Milos Kleint
Details | Diff
maven impl (13.38 KB, patch)
2007-05-30 08:07 UTC, Milos Kleint
Details | Diff
maven impl (13.38 KB, patch)
2007-05-30 08:09 UTC, Milos Kleint
Details | Diff
api and implementation in maven projects (18.02 KB, patch)
2009-02-10 14:45 UTC, Milos Kleint
Details | Diff
use by junit modules (8.79 KB, patch)
2009-02-10 14:46 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2007-04-27 09:50:36 UTC
when a sourcegroup of a particular type doesn't physically exist, then it cannot
be included in the Sources instance. That's because of the
SourceGroup.getRootFolder() method which returns a fileobject.

That's a problem in situations where the location of a potencial SG is known,
but not created by the project template (or deleted by the user).
Fo that reason, UI like the New File Wizard, or Create JUnit Tests won't work
for such cases and the user has to create the folder first outside of the IDE or
in Files View before proceeding with the mentioned actions.

a possible solution would include
adding a method to Sources
PotentialSourceGroup[] getPotentialSourceGroups(String type)
and another method to SourceGroup
File/URL getPotentialRootFolder()
Comment 1 Milos Kleint 2007-05-30 08:05:42 UTC
Created attachment 42932 [details]
initial diff
Comment 2 Milos Kleint 2007-05-30 08:07:56 UTC
Created attachment 42933 [details]
maven impl
Comment 3 Milos Kleint 2007-05-30 08:09:11 UTC
Created attachment 42934 [details]
maven impl
Comment 4 Milos Kleint 2009-02-06 16:28:35 UTC
an easier to integrate solution would be to create a new interface like
SourceGroupProvider that would reside in project's lookup.

the signature could be
SourceGroup createSourceGroup(String type, String hint);
where type is something like java, doc_root, scala, resource etc. and the hint would be some kind of constant that would
let us distinguish between test java sources and regular java sources for example.
That would be sufficient for junit support in #96266 
for #97170 we would need an additional method like
SourceGroupCreator createSourceGroup(String type, String hint) that would just expose an instance of SourceGroupCreator
.
That would have methods like File getRoot() + String getName() and also a SourceGroup createSourceGroup() method for the
final SG creation.
That could be reused in form module+maven hack which currently relies on "resource" sourcegroup getting eagerly created.

jglick: viable for 7.0? to me it seems to be much easier to integrate than the initial idea and could be easy enough to
use..
Comment 5 Jesse Glick 2009-02-06 19:19:38 UTC
SourceGroupModifierImplementation would I guess be the appropriate name for the project service, by analogy with
ClassPathModifierImplementation, and then SourceGroupModifier for an API. Your SourceGroupCreator could also be called a
SourceGroupFuture, perhaps.

I think it is feasible for 7.0 if you want to prepare it. Clearly all project types would benefit from having an impl,
so they can add a test root.
Comment 6 Milos Kleint 2009-02-10 14:45:48 UTC
Created attachment 76794 [details]
api and implementation in maven projects
Comment 7 Milos Kleint 2009-02-10 14:46:15 UTC
Created attachment 76795 [details]
use by junit modules
Comment 8 Milos Kleint 2009-02-10 14:48:55 UTC
api change included along with a sample implementation in maven projects.
the second attachment patches the junit module to make use of the new api, please note that I took the minimum changes
approach to patching junit, it could be rewritten more effectively.

please review
Comment 9 Milos Kleint 2009-02-17 06:39:50 UTC
thanks for review, I will integrate tomorrow
Comment 10 Milos Kleint 2009-02-18 11:32:27 UTC
api contract and maven project type implementation:
http://hg.netbeans.org/main/rev/d2c4d648ef70

use in junit module:
http://hg.netbeans.org/main/rev/e2a4b4dc410a

use in swingapp module
http://hg.netbeans.org/main/rev/f931ce14eec2
http://hg.netbeans.org/main/rev/eba9336b8def
Comment 11 Jesse Glick 2009-02-18 15:01:02 UTC
Please add a note to Project.getLookup Javadoc suggesting that a SourceGroupModifierImplementation be included.


Assuming that impls are added for j2seproject, apisupport.project, etc., we should consider whether various New Project
wizards ought to create the test source root by default, if it is now so easy to add tests later.


Complete the Javadoc for Future.


Sorry for the late review and if I am missing something obvious, but [JG01] what is the purpose of
createSourceGroupFuture? The Future object does not provide any more information than what you passed to cSGF. You could
just call cSG later if that's what you wanted. I thought the whole purpose of this was to have a method such as URL
getFutureRootFolder() which would not actually create the SourceGroup yet - but there is no such method, and nothing in
SGMI to support it. Nor is there any usage in o.n.m.junit.wizards.* where I would expect it (because you do not want to
actually create the folder unless and until Finish is clicked).
Comment 12 Milos Kleint 2009-02-19 11:44:55 UTC
added javadoc and a new method in SGMI to make sure to create a Future object only if the creation of the SG for the
given hint+type is supported.

http://hg.netbeans.org/main/rev/7d3ac2fb6af3
http://hg.netbeans.org/main/rev/3108ea12487f

the future object is not used in junit module because I took the path of least resistance there. delaying of fileobject
creation in the wizard seems like a more complex task, I don't unfortunately have time nor expertise for that..
I'll look into the java module templates if they are simpler to convert, if not I guess we should remove the Future
class until it's really needed.
Comment 13 Quality Engineering 2009-02-22 08:05:09 UTC
Integrated into 'main-golden', will be available in build *200902220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/d2c4d648ef70
User: Milos Kleint <mkleint@netbeans.org>
Log: #102711 add api that allows to create SourceGroups of given type if not pre-existing. Includes implementation for maven project's main and test java source roots.
Comment 14 Jesse Glick 2011-02-09 21:34:15 UTC
(In reply to comment #11)
> Assuming that impls are added for j2seproject, apisupport.project, etc., we
> should consider whether various New Project
> wizards ought to create the test source root by default, if it is now so easy
> to add tests later.

See: bug #195254


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo