Although it's not common to deploy composer packages, because they should be handled by the remote composer, I'm still curious...
In PhpStorm when I select my project (root) and choose to deploy with Sync with deployed to..., all files and folders get synced/uploaded, except for the child folders of composer's vendor folder.
I only see 1 option to exclude items (by name) which contains .svn;.cvs;.idea;.DS_Store;.git;.hg;*.hprof;*.pyc and I don't have any Excluded Paths configured at the deployment server configuration.
Seems to me there are no mentions about composer related files/folders.
Did I miss some settings which do exclude those child folders or isn't PhpStorm capable to deploy them?
Any suggestions on how to configure PhpStorm to do sync/upload the child folders are welcome.
If you go to Settings/Preferences | Directories you will see that those folders are (extremely likely) marked as Excluded ... which do not not participate in such deployment operations.
vendor folder most likely means Composer ... and Composer integration in PhpStorm automatically marks all packages as Excluded and then re-adds them back as "PHP Include path" entries (Settings/Preferences | Languages & Frameworks | PHP) -- this allows separating your own code from 3rd party one: you do not wish to see/to be warned about any errors/warnings in that code (as part of your code analysis) or see their TODOs in your TODO list, or see matches from that code when you do refactoring or just searching for something (although search is flexible so you can search even there of so desired).
This behaviour is controlled by Settings/Preferences | Languages & Frameworks | PHP | Composer --> Add packages as libraries option.
Related
I have successfully built a number of projects with eclipse (mars) under windows 10 with copied common source and header files. I now want to refactor these projects to use the eclipse 'linked folder' facility.
linked folders
I have successfully created the common project and the linked source folders to it in the target project.
However when I try to compile the project the compiler can't see the linked folders...
compiler error messages
I'd appreciate any help with this, or is it that the xtensa compiler under windows doesn't support linked folders??
IMHO "linked folders" is a slightly borked feature as it raises expectations it can't fulfill. The folders are only linked within the Eclipse context. That means that as soon as you leave the safe Eclipse haven those links are gone.
What you actually want/need are links on OS level that also work on the command line i.e. you need them on the file system. Such symlinks are native on Unix(-like) systems but there are ways to create them on Windows as well.
We have some Maven modules shared between several teams, with the mandate to share the source code even though our projects use different dependencies and resources. To accomplish this, we have our modules set up as recommended in Using Maven When You Can't Use the Conventions under "Producing Multiple Unique JARs from a Single Source Directory." Specifically, we have a shared parent module containing the src directory but whose pom declares <packaging>pom</packaging> and only builds the two submodules. Each submodule inherits from this parent and refers to the shared src directory using this:
<build>
<sourceDirectory>../src/main/java</sourceDirectory>
</build>
The two submodules have different artifact ids, allowing dependent modules and projects to specify which version and dependency set they need. It also upholds the Maven principle of "one module, one output."
This all works great in Maven-land: compilation, installation, deployments, etc. What doesn't work well is Eclipse integration. Some things work fine: building the modules, deploying to our Maven repo, pulling in dependencies to build our project. But things such as code completion and jumping to class/method definitions do not work at all. It's as though Eclipse doesn't recognize the source at all.
If we just check out a module from SVN, Eclipse doesn't know about the classes but instead uses jars from the repo. If we then import the modules as Maven modules, they show up in package explorer and the project build path. However, all references to those classes and methods are now flagged as errors by Eclipse. And we still do not have code completion or navigation.
So my questions are these: How can we get Eclipse to recognize the code and do its normal code navigation while still satisfying our varying project requirements? Am I missing some simple Eclipse configuration? Do we need to rework our Maven module structure, and if so, how?
Some additional context: The different dependencies for the projects are rather large, including different major versions for things such as Weblogic and Spring. The Weblogic versions will converge some time next year, but the other dependencies will be slower (and some resource files will likely always remain distinct). So for the near- to mid-future, we have to account for different dependencies between the projects.
We are using profiles to allow our Jenkins server to build both submodules while allowing individual developers to build only the submodule their project needs. Using profiles to manage the dependencies is problematic because we lose transitivity of dependencies.
Update (12/8/15)
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, but Link Source let me assign an arbitrary directory to use. It's not ideal, but it seems to be working.
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, which derailed me for a while. However,Link Source let me assign an arbitrary directory to use.
It's not ideal, but it seems to be working. We can now jump to definitions with F3, and errors are now highlighted correctly. It's good enough that I don't feel bad recommending it to the other team. I wish Eclipse would automatically allow a parent source directory to be referenced, but at least the manual intervention worked right.
Here's the structure of my web development project:
Web Project
Content
My Theme
Content
Less
Scripts
etc.
When I install Less Bootstrap Package, it always installs the files in the content directory:
Web Project
Content
bootstrap
My Theme
Content
Less
Scripts
etc.
I want it to install the files here:
Web Project
Content
bootstrap
My Theme
Content
Less
alerts.less
badges.less
etc.
Scripts
etc.
Is there a way to specify the target path for source files? I haven't seen any documentation on it and the only questions I've seen about this pertain to specifying where the .package files are installed. I have a difficult time believing that this option doesn't exist, especially considering that developers are very finicky about how they organize their source trees.
Currently this is not supported by NuGet. The location of the files is defined by the NuGet package and currently cannot be overridden.
There is an open work item where this problem is discussed with proposed solutions but it has not yet been implemented.
When i click add in the target-editor i can choose between:
Directory (just plug-ins on the filesystem)
Installation (only plug-ins, too?)
Features (one or more from the filesystem)
and Software Site (e.g. p2-repository)
So what's the difference between a installation (such as eclipse-SDK) and a directory, when the installation just fetch the plugins? I thought a installation would resolve my features, too. But it seems there is another difference, so what's the benefit?
Edit: Note if you want to use features with the type "installation", it's necessary to unjar the features.
An Eclipse installation contains metadata as to what was installed via Help -> Install New Software and other similar means. Since the installation process verifies dependencies, you know that your target platform is valid and will run. Defining target via an install will use the install's metadata to populate the target. Note that Eclipse has not been automatically detecting plugins copied into the plugins directory for several years now.
If you define a target by pointing at a folder that you put together by copying plugins, you do not know if the dependencies of those plugins are satisfied, so your target may not run.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.