Maybe it was discussed before, but cannot we add some optional properties
(file) to a directory that contains a project (or located it for example in
nbproject dir) and later check presence of this property in isProject
method?
I mean something like this :
public @Override boolean isProject(FileObject fileObject) {
....
if (PREFERED_PROJECT_TYPE exists and PREFERED_PROJECT_TYPE is not
maven) {
return false;
}
File project = new File(projectDir, "pom.xml"); // NOI18N
if (!project.isFile()) {
return false;
}
....
For the start we can update only maven project and other types of project
we can update later (per request)
Jakub
On Wed, Jan 23, 2019 at 10:38 AM Christian Lenz <christian.l...@gmx.net>
wrote:
> Hey Attila,
>
> thx for the info.
>
> As mentioned, I have the same with the Puppet plugin. I only wanted to use
> the plugin for syntax highlighting pp files and some other features, but
> it finds the vagrant.pp and init.pp file and changes the project type to a
> puppet project, which makes the project unusable as a HTML5 project. See
> here the ticket: https://github.com/tropyx/NetBeansPuppet/issues/27.
>
> So again, there is the feature of activating/deactivating NodeJS support
> for a HTML5 project, which changes the Icon and I think some of behaviours.
> So why not activating/deactivating other project features? Like Maven or
> Gradle or whatever? Yes maybe the background process could be a problem.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Attila Kelemen
> Gesendet: Dienstag, 22. Januar 2019 16:49
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Activating project type features in different project type
>
> Actually, I have had mutliple complaints about this in the past. Almost
> always (the exceptions were, when there are multiple build tools
> temporarily, due to porting between build tools), the issue was the
> presence of the `package.json` (implying a particular project type). That
> said, I don't know who this could be safely changed in NB. If it were only
> this JS project type, then I guess there is not much conflict because there
> could be a wrapper for `Project` merging all project types volunteering to
> accept that project. However, if it is say Ant+Maven+Gradle, then they will
> have lots of conflicting queries on the project lookup. If the user could
> essentially change whose lookup is proxied, then it might work in theory
> but who knows what backgroud process may break because it assumes project
> type permanence. Though I could say, that I tried to not rely on that, I
> saw in many plugins that this is not usually the case and people heavily
> build on the assumption (implicitly) that project types do not change.
>
> So, I'm not very optimistic that this could be changed. Making a special
> case for JS projects seem more plausible.
>
> Attila Kelemen
>
> Emilian Bold <emilian.b...@gmail.com> ezt írta (időpont: 2019. jan. 22.,
> K,
> 10:13):
>
> > > At the end, I need to find a proper solution for that, I can’t be the
> > only one who has this problem. I already have it with 3 projects.
> >
> > You are literally the only one to have ever complained about this. At
> > least from what I can remember.
> >
> > Having a user-configurable priority for project types might make
> > sense, I guess. But you could also just disable modules entirely and
> > the the support goes away (I guess this is what a project 'switcher'
> > would do?)
> >
> > I'm just not certain this is something the IDE should support
> specifically.
> >
> > As an implementation detail: I worked a fair bit last year with the
> > Project API and implementation. There are a lot of assumptions there
> > that you might need to tweak in order to recognise multiple Projects
> > for a FileObject. This will not be an easy PR to make.
> >
> > And it doesn't even look to me like you want to pick *one* project,
> > you want an amalgam of features from various project types.
> >
> > --emi
> >
> > http://coolbeans.xyz/ - CoolBeans: An IDE for Java, JavaEE, PHP and
> more!
> >
> > On Tue, Jan 22, 2019 at 10:59 AM Christian Lenz <christian.l...@gmx.net>
> > wrote:
> > >
> > > Hey,
> > >
> > > there is a Long discussion going on here:
> > https://issues.apache.org/jira/browse/NETBEANS-1802
> > >
> > > In short, I have the problem that NetBeans, forces me into one project
> > type (here maven) when there are two or more files/folders of different
> > Project types (pom.xml, package.json, etc.). So my case I have a project
> > with a pom.xml and a package.json and NetBeans opens that project as
> maven.
> > Which is not correct. But removing the pom.xml is not working, because I
> > need it. So I preferred a project type switcher, but in the end as
> Geertjan
> > and Milos already said, that doesn’t make sense. So in general it would
> be
> > good to activate features from one project type into the other but not
> all
> > at the same time. Because this will be a mess, mixed HTML5/JS Actions
> with
> > Maven Actions, build/run will not work, because which will win?
> > >
> > > There is another discussion with Geertjan and Milos but in private, I
> > will summerize some Infos here:
> > >
> > > TLDR;
> > > Milos wrote:
> > >
> > > „Yeah, not really much to add there that wasn't already mentioned in
> > https://github.com/tropyx/NetBeansPuppet/issues/27 .
> > > project types are semi-automatically identified by certain files in a
> > directory and each directory can be exactly one project type. That's a
> core
> > feature of netbeans project system. To allow switching you woud need to
> > create one project type to bind them all. But really, you don't want a
> > project type switcher, you want features from one project type in the
> other
> > project type. That's how maven war/ear/ejb/apisupport support works,
> > bridging editor features for certain content and have them available in
> the
> > other. That's generally quite a bit of work for individual features and
> > sometimes the bridging could be shady.
> > >
> > > Alternatively you can just rewire your content to be 2 projects in 2
> > directories. There still could be rough edges to it but it's likely the
> > easiest way out.
> > >
> > > Milos“
> > >
> > >
> > > Me again:
> > >
> > > „That could be another thing. As I said like the feature
> > activation/deactivation which is already possible in HTML5 -> NodeJS. I
> can
> > activate/deactivate nodejs features.
> > >
> > > But I don’t want all features of both project types in one project.
> That
> > will be a mess of actions shown in the context menu. To many project
> > options, because now we have 2 projects. And what will happen for
> > build/run? What will win? I will hit run or build and for me I need to
> > change the building pipeline to node with grunt/gulp or npm and not using
> > maven for this. So yes, It would be nice to have features from one
> project
> > into the other one, BUT I will decide by my own whether I want them or
> not.“
> > >
> > >
> > >
> > >
> > > So here is my proposal how that could work:
> > >
> > > I prefer not being a dominant project, because the plugin for puppet
> > dominants in this case. If there are problems with some projects with 2
> > different project types, I would expect a warning on the project with an
> > Icon of a non specific project type and the exclamation mark as we have
> it
> > for other projects with problems, that I can resolve (Missing
> dependencies,
> > missing NPM installed, missing Bower, etc.).
> > >
> > > If I resolve such a project I can choose which project type I want, by
> > my own, not by NetBeans (Only for multiple project types). And when I
> > choose one, for example HTML5, it should be saved as my default. And with
> > this project type which could be maven and my saved HTML5, I should
> > add/activate Maven features, because it is possible of that specific type
> > of project.
> > >
> > >
> > > At the end, I need to find a proper solution for that, I can’t be the
> > only one who has this problem. I already have it with 3 projects.
> > >
> > >
> > > Cheers
> > >
> > > Chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
>
