I'm switching an old web-application to using Maven rather than Ant. It goes mostly fine, but there is one thing I'm not sure about.
With customly written Ant build file I had a "development deployment mode", where it would symlink certain files (JSP and certain others) rather than copying them. This would result in a very streamlined development procedure: once you have deployment running, you just edit files in your source code checkout directory, and webserver picks up these changes automatically. Basically, you edit something in your editor, save file, and in a few seconds the changes automatically become visible through your browser, without any further steps.
How would I go about implementing something similar with Maven?
While this doesn't seem possible without writing a custom plugin, I found war:inplace goal in maven-war-plugin, which achieves what I want. The only downside is that I have to keep JSP files, JS files, images etc. together in src/main/webapp rather than have them logically separated in e.g. src/main/jsp, src/main/js, but that's not that important.
Related
I come from Grails background and there was a feature where our changes to CSS, HTML & JS files were instant and didn't needed rebuilding code again.
Now, while building a Micronaut project I would like to have something similar but I am unable to figure how to configure Gradle for same.
Till now, I found out if I make changes to copied resources inside build folder, changes are reflected on browser and don't require rebuilding code but this forces me to do changes to original file later.
Can I somehow make Gradle directly use src/main/resources from it's original location rather than Gradle copying it to build folder?
You might be looking for ./gradlew run --continuous but depending on what things you are changing in the resources/ folder, those changes may nor may not affect the running app without restart.
More information is available at https://docs.micronaut.io/1.1.2/guide/index.html#reloading.
I hope that helps.
Few days back I created a maven project and i'm using angularJS for view, but whenever i make changes in the html file it doesn't show up after running the project, i clean the project countless number of times but the changes still don't show up.
But what i don't understand is that sometimes the changes show up the next day I run the project.
So is there some kind of cache that i need to delete after making new changes to my project??
I'm using STS Version: 3.3.0.RELEASE.
Thanks,
-Elysium
It sounds like your JavaScript files are not being copied over to the target directory properly. Make sure that after you do a build in the workspace that the proper version of the JS files are in the target folder on the filesystem (i.e., look outside of Eclipse). If the files are not correct, then your maven commands are not being completely invoked inside the workspace.
It's hard to say exactly what is going on without more information, but this sounds possible.
I'm in the process of updating our build process for Android to use gradle. We have client-specific apps - i.e. a single code template which is used as the basis for all the apps which are created dynamically.
To build the apps, I loop through a CSV file to get the details for each one. I then take a copy of the source template, inserting the client's name, images, etc. before compiling the app. This works fine in the current system. In the gradle version, I've got it successfully looping through the rows and creating the app source for each one with the right details. However when I try to actually build the app, it fails with the message:
Project with path ':xxxxxx' could not be found in root project 'android-gradle'.
From reading the documentation, I understand that this is because the project doesn't exist during the configuration phase as it's not created until the execution phase. However what I haven't been able to find is a way around this. Has anyone managed to achieve something similar? Or perhaps a suggestion for a better approach?
One option is to script settings.gradle. As in any other Gradle script, you have the full power of Groovy available. Later on you can no longer change which projects the build is composed of. Note that settings.gradle will be evaluated for each and every invocation of Gradle, so evaluation needs to be fast.
While Peter's answer pointed me in the right direction, it ended up not being a workable solution. Unfortunately with nearly 200 apps to build, creating a copy of the source for each one was too big an overhead and gradle kept running out of memory.
What I have done instead is to make use of the Android plugin's product flavors functionality. It was quite straight forward dynamically adding a productFlavor for each row in the CSV (and I can do that in build.gradle rather than settings.gradle), and I just set the srcDir to point to the relevant images etc for each one.
What to commit and what to ignore when adding a flex project to github?
Keep in mind that I want to share it with others and accept pull requests.
I don't use flex, but here are some general rules for all source control:
Commit:
Human written code
Configuration files
Referenced 3rd party libraries (that are not typically part of the standard environment)
In some cases tools needed to build and run that are not standard (save people hunting and downloading if you can)
Ignore:
Generated code, that can be easily regenerated using a scripts, tools
Generated CSS files if you write SASS/SCSS/LESS instead
Generated JS files if you write Coffeescript instead
Build artifacts, build folders,
Temporary files (e.g., some editors creating working files)
As an addendum for Git, I prefer to keep some non-code artifacts in submodules to avoid polluting the code repository. This can include:
Large assets, images and videos in some cases
Tools and executables (very handy if you reuse these tools for multiple projects)
This is not an exhaustive list and your environment probably dictates some deviation or adjustments here. The first rules in
I have a relatively simple goal: I want to create a Cocoa application which doesn't have much functionality itself, but is extendable through plugins. In addition I want to work on a few plugins to supply users with real functionality (and working examples).
As I am planning to make the application and each plugin separate open-source projects (and Git repositories), I'm now searching for the best way to organize my files and the Xcode projects. I'm not very experienced with Xcode and right now I don't see a simple way to get it working without copying files after building.
This is the simple monolithic setup I used for development up until now:
There's only one Xcode project with multiple products:
The main application
A framework for plugin development
Several plugin bundles
What I'm searching for is a comfortable way to split these into several Xcode projects (one for the application and framework) and one for each plugin. As my application is still in an early stage of development, I'm still changing lots of things in both the application and the plugins. So what I mean by "comfortable" is, that I don't want to copy files manually or similar inconvenience.
What I need is that the plugin projects know where they can find the current development framework and the application needs to know where it can find the development plugins. The best would be something like a inter-project dependency, but I couldn't find a way to setup something like that in Xcode.
One possible solution I have in mind is to copy both (the plugins and the framework) in a "Copy Files Build Phase" to a known location, e.g. /tmp/development, so production and development files aren't mixed up.
I think that my solution would be enough, but I'm curious if there's a better way to achieve what I want. So any suggestions are welcome.
First, don't use a static "known location" like you mention. I've worked in this kind of project; it's a royal pain. As soon as you get to the point of needing a couple of different copies of the project around (for fixing bugs in parallel, for testing a "clean" build versus your latest changes, for working on multiple branches), the builds start trashing each other and you find yourself having to do completely clean/builds much more often than you'd want.
You can create inter-project dependencies by adding the dependent project (Add File), right click the Target and choose "Get Info," and then add a Direct Dependency on the General pane.
In terms of structure, you can either put the main app and framework together, or put them in separate projects. In either case, I recommend a directory tree like:
/MyProject
/Framework
/Application
/Plugins
/Plugin1
/Plugin2
Projects should then refer to each other by relative paths. This means you can easily work on multiple copies of the project in parallel.
You can also look at a top-level build script that changes into each directory and runs "xcodebuild". I dislike complex build scripts (we have one; it's called Xcode), but if all it does is call "xcodebuild" with parameters if needed, then a simple build script is useful.