I am creating a project that has two flavors
one for enterprises and one for families .
the deferences are simple really : changed labels(property) , changed colors(CSS) , a few deleted features...
i don't want to start a new project and copy the whole enterprise to the family version because that would mean that each bug must be solve in both .
technology used :JSF,Jquery,Hibernate and eclipse as an IDE also I am deploying to Jboss.
i dont know where to start but i have the following thoughts:
solution attempt 1 :
along time ago when i used to develop J2me application on netbeans we used to have something called configurations where we can choose to include deferent segments of the code depending on the configuration(device) so we would end up having multiple executable files.
solution attempt 2:choose which code is common and move it to a separate location and include it in both projects (this would be painful to implement and also i need to replicate some fixes some times)
is there any good solution to this issue ?
thanks
Consider using a repository (git, svn) - create a branch for each of the versions, and then when you fix something on one of the versions, merge it to the second. With git you can have a local repo just for your own on local machine, and it's really simple to set up.
Related
Been working with Nifi for a few months and noticed a dependency pattern that doesn't make sense, hopefully I can describe it clearly in case someone can shed light.
We've been prototyping several related but distinct custom processors, and these processors all use some common jar libraries.
For example,
Processors A and B use Library1
ProcessorA gets developed along with some of the code in Library1, build Library1 and then build ProcessorA for testing on the NiFi server, all is good
ProcessorB gets developed also with some of the code in Library1, and Library1 is rebuilt before building ProcessorB as a deployable nar
Then when testing ProcessorB on the NiFi server (including attaching to the process to step through) we find need to update relevant code in Library1
But, despite this update to the Library, ProcessorB still executes the old Libary code. A specific example was a for loop; it would still initialize int i = 1 after I changed the code to int i = 0.
Only after I did a clean/rebuild of ALL the processors (both A and B) did ProcessorB start recognizing the updated library code.
This is surprising since every processor nar package should have its own copy of the library jar, but it is acting like the earliest version takes precedent.
My question, finally: is this expected behavior when using shared code libraries among nar packages, or is there a better practice for architecting these? Or am I missing some wisdom from from the java/maven realm?
NiFi is v 1.8 but also experienced this in 1.5
Many TIAs
I recently started developing a plugin, which consist of several Eclipse Plugin-Projects. I use Maven/Yycho as a build tool and GitHub as version control system.
Now I was wondering what to push to my GitHub repositories. The POM files and Feature/Updatesites as well? It seems that this stuff is:
very User specific (the path are relative to the file structure on my computer)
do other developers need that stuff or should I give them the freedom of choosing their own build tools?
To clarify, I have right now 6 Eclipse projects:
*.plugin1
*.plugin1.tests
*.plugin2
*.releng
*.feature
*.p2updatesite
Would it be good practise to share everything? From my feeling I would say I will only share plugin1+tests & item # 2 (without the pom files) so that everyone can take care themselves about building.
You don't have to add to your repo:
anything that can easily be regenerated
anything with local paths specific to a user
Regarding building, ideally you should version at least a script able to generate the right pom, in order for a new contributor to be able to get going as fast as possible after cloning it.
If you can have config files with only relative paths (instead of absolute one), then you can include those, for others to use.
See for instance ".classpath and .project - check into version control or not?".
I have a Swing/Java application that is being used for clients and has weekly updates.
The problem is the setup just lay out the classes and their respective directories and on the update I just update the classes.
I want to do a single jar containing all the classes, but I'm not sure how would I be able to update it...
Also some clients need some updates during the week where only one or two classes would be updated.
What is the right way of doing this ?
Im using Eclipse.
EDIT: I know how to create the jar, I just dont know how to dynamically update it.
I would suggest you look into Java WebStart which is designed to do exactly what you need.
You need to first create the finished deployment and then you can look into creating a JNLP file for the deployment, and a way to put all the files to a web server for the user to access. For now just let the user download the whole thing every time you update. When you get more experienced you can look into how you can make incremental updates.
I would strongly recommend including a build number or timestamp in the deployment paths so a jar file is not cached incorrectly in the client by accident.
The general way of doing this, even if only small changes were made, would be to repackage your JAR after each update and give that JAR to a user. The user would replace the existing JAR. How you produce your JAR is up to you. Many IDEs support it, you could write a shell script, use existing build systems like ant or maven or even make, whatever. (See edit below)
If your JAR is very large and deployment is cumbersome, you may be able to split your project into smaller subcomponents, each with their own JAR, and only redistribute the ones containing changes. That may or may not be a major refactoring for you, and it might not even be appropriate. For most small or average size projects, this is generally unnecessary.
As for deployment, there are also a zillion ways to make that easier on the user. You could just give them a JAR file. You could use e.g. install4j. You could use Java Web Start (although its kind of clunky). There are others.
Both install4j and JWS support automatically checking for updates. If you choose to support that feature, all you would need to do is update your distribution site, and users would receive updates automatically. That's also up to you.
But a short answer to your question is: If you have all of your classes packaged in a JAR, no matter how many classes change, you'll want to give the entire updated JAR to the user. The benefit that counters this cost is that a JAR is a nice, compressed, self-contained collection of your application/library's source, which makes management and deployment very convenient.
Edit: Responding to your edit where you specify that you are using Eclipse, Josh M gives you instructions in his comment on your answer. To add to his comment, to export a Runnable Jar you'll have to have a Run Configuration set up which, if you've been running your application in Eclipse already, you probably already have. If not you can create one in the Run menu.
Edit 2: Please refer to Thorbjørn Ravn Andersen's answer as well for some good JWS tips.
I have an app written with GWT and GAE where every supported city has its own app. Clearly this is not the best way to manage the map so I want to merge them all into one app. Currently my app is at the urls sub1.myapp.com, sub2.myapp.com, sub3.myapp.com, etc, and I want them to be at myapp.com/sub1 ,myapp.com/sub2, etc. All the supported cities share common code, so I'm going to put all the that code in one module, and have a different module for each piece of unique code block. Is this going about it the right way? How will the different modules interact?
Also, I currently have JSPs at sub1.myapp.com/listofsomesort and I would like to move these to myapp.com/sub1/listofsomesort. Is there a simple way to accomplish this?
By making a module with EntryPoint for each old application, in one and the same application. Each module has one 'welcome page' which you can put in different directories. All the shared code can go into another module. The shared code can be used by the inherit setting in other modules.
The only thing I bumped into was that when you deploy to GAE, ALL modules should have an entry point, also the library modules. I solved it by adding a dummy EntryPoint to them, that does nothing, but still searching for a better solution. See my question at How to deploy GWT Project containing GWT modules without entry points with Eclipse GAE plugin?.
This seems like the job for Code Splitting :) It might require some changes in the structure of your code, though - depends how tightly coupled your classes are. A compile report should tell you if your code splits up nicely, or if not, where the connections are.
I am working on a small team of web application developers. We edit JSPs in Eclipse on our own machines and then move them over to a shared application server to test the changes. I have an Ant script that will take ALL the JSPs on my machine and move them over to the application server, but will only overwrite JSPs if the ones on my machine are "newer". This works well most of the time, but not all of the time. Our update method doesn't preserve file change day/times, so it is possible that an Update on my machine will set the file day/time to now instead of when the file was actually last changed. If someone else worked on that file 1 hour ago (but hasn't committed the changes yet), then the older file on my PC will actually have a newer date. So when I run the Ant script it will overwrite their changes with an older file.
What I am looking for is an easy way to just move the file I am currently working on. Is there a way to specify the "current" file in an Ant script? Or an easy way to move the current file within Eclipse? Perhaps a good plugin to do this kind of stuff? I could go out to Windows Explorer to separately move the file, but I would much prefer to be able to do it from within Eclipse.
Add a target to your ant build file to copy a single jsp using a command line property definition as #matt b described.
Create a new external tool launch profile and use the "String Substitution Preferences" to pass in the reference to the active file in the editor (resource_name).
See Eclipse Help | Java Development User Guide | Reference | Preferences | Run/Debug | Launching | String Substitution
How would Ant know what file was "current"? It has no way of knowing.
You could pass the name of the file into your Ant script (by taking advantage of the fact that any arguments you pass into Ant with -D are automatically parameters in your script)...
ant -Dfile=myfile.jsp update
and have your script look something like...
<copy file=${myfile} todir="blah"/>
...but it would probably be a pain to constantly type in the name of the file on the commandline.
Honestly, the type of problem you've described are inevitable when you have multiple developers sharing an environment. I think that a better approach for you and your team long-term is to have each developer work/test on a local application server instance, before the code is promoted. This removes all headaches, bottlenecks, and scheduling trouble in sharing an app server with other people.
You should really use source control any time you have multiple people working on the same thing (well, you should use it any time regardless, but that's a different conversation). This way, when conflicts like this occur, the tool will know and make someone perform the merge so that no one's changes get lost. Then, the test server can run on a clean checkout from source, and each developer can also test the full application locally, because everyone's changes will be instantly available to them through the source repository.
I suggest you to use source control. I prefer Subversion. You can use CruiseControl to make the build automatically whenever someone commits new code.
The antrunner4e plugin is exactly what you are looking for -- see http://sourceforge.net/projects/antrunner4e/