Worklight - How to checkout from SVN and keep apps structure - eclipse

I am trying to add an existing worklight project to my SVN repository which went fine (removed the .project, .classpath files and the .settings folder). However I am having trouble with checking it out on a different PC. If I check it out using subclipse in Eclipse and as a new Worklight project it removes my apps folder and creates a new one thus removing my created files for Android\iPhone\mobile.
If I check it out normally it is not detected as a worklight project by the Worklight plugin.
Anyone that can help me out?

.project and .classpath needs to be checked in, they define the properties of your project. .settings folder is optional, however I'd recommend checking it in as well.
In general, this page outlines what you need to checkin and which files/folders should be ignored - http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fr_integrating_with_source_contro.html&resultof%3D%2522%2573%2576%256e%2522%2520

Related

Issues with Liferay 7.1 workspace imported from Github

I have cloned my Liferay 7.1 workspace from my Github repository. When I try to get Assistance in Liferay IDE using Control+Space, I get error:
This compilation unit is not on the build path of a java project
This happens on the new module project created in the same workspace(that was cloned from Github).
But when I create/import module from my local workspace that was created by Liferay for first time, this issue is not there.
I feel like there is some extra workspace setting that I am not doing in my Github workspace. Like we had to create build.username.properties in the SDK folder for Liferay 6.2. Totally stuck and no solutions anywhere.
I tried fixing Project Build path and Project Facets but did not help.
The way you did it in your own answer obviously solved it. My take on this is: The problem was most likely the .project file, because it contains all the configuration that eclipse requires, and the error message you post is an indicator that eclipse doesn't know what to do with these files.
The .project file can be regenerated from gradle settings, typically by choosing "gradle / refresh" (from memory, from the context menu of the project/workspace in Project Explorer), which will read the gradle settings and apply them to the eclipse world. This might happen automatically, but it might also need some manual push - next time you might want to try this, because just copying random files rarely is a good idea. You might end up pointing to other directories far outside of your workspace, and wonder why a local change is not picked up.
There were some differences between the workspace that I imported from Github and the one that Liferay was creating on my local. I opened both the workspaces in Beyond Compare. Following are the files that had major differences. I made them same and it started working after Gradle Refresh in Eclipse.
liferay-workspace/gradle/wrapper/gradle-wrapper.properties
liferay-workspace/.project
liferay-workspace/gradle.properties
liferay-workspace/gradlew
liferay-workspace/settings.gradle

Permanently fix the Eclipse error "project description file (.project) is missing"

Every time I boot Eclipse I get the error "The project description file (.project) for my project is missing".
As other StackOverflow answers have show, this is easy enough to fix: delete package from Eclipse and import it again. However, if I close and reopen Eclipse the error will be back. I have not found a permanent solution yet.
I have my workspace in my Dropbox, but at some point I decided it was time to start using Git. I don't really get Git but they say you have to put the .project file in your .gitignore because it is computer specific.
This I feel is the origin of the problem, but if I don't do any git related activities (push, commit, etc.) I still get this error.
How do I fix this once and for all?
A .project is a Eclipse-specific file that tells Eclipse about how the project's struture is placed in the project's hierarchy.
It's normal for this file (and other Eclipse specific files) to not be committed because other people participating on the same project may use other IDEs of their choices (intellij, and so on), so the content committed in your VCS is 'neutral' for IDEs.
When you create a project from inside Eclipse, the .project file shall be created along. But when you import into Eclipse an existing project, there are ways to generate locally the .project , .classpath and other Eclipse-required files. Maven, Gradle and Ant are some examples of tools that do this.
Finally, I recommend to keep these files in .gitignore so the project's contents in VCS will remain neutral to IDEs. So you will not bother other people using other IDEs.
So, the steps are:
Check out the project
Generate the eclipse files using maven, ant or gradle. If your project already uses a tool such as these, thats nice
Check if the project is OK inside eclipse (compiling, no errors)
Add the newly generated eclipse files to .gitignore
commit and push the .gitignore.
.project is not machine-specific as long as everyone on your team has the plug-ins installed for that kind of project. .classpath might be if you don't do things right. This is your project, though, so commit your .project.
Keeping .classpath clean largely revolves around keeping machine-specific paths and references out of it:
Set the project's JRE using an Execution Environment. It is an indirect way of saying what version you need, then the IDE figures it out for that machine. The stored value defaults to using the name of your default Installed JRE in the preferences, which is very machine-specific.
Put the jar files you need into the project, or into another project that this one can refer to. They go into source control as well for the sake of repeatability, unless you're using a tool like Maven, in which case be specific about the version you require where ever you state that dependency and make sure the relevant M2E plug-ins are installed.

IBM Worklight - How does Worklight detect the project version?

Recently we'd updated our Worklight platform with the latest Fixpack (6.1.01) and everything works fine after the update.
However although we had check in all our files into our SVN repository, when we check out a fresh copy of project, the eclipse Worklight plugin will still perform an upgrade to the project.
Is there a Worklight platform version control in the project folder that we missed out and didn't commit to the repository? or is there extra setting that we need to apply before checking into the SVN repo?
Any clues will help, thank you.
EDIT
Below is the print screen taken from the SVN Repository browser in eclipse. We use Windows environment for development. The .settings folder is inside the repo.
EDIT 2
After inspecting the org.eclipse.core.resources.prefs file in the .settings folder, i notice that there's this line of properties that are not updated in the repo:
wl_version=6.1.0.00.20131219-1900
Is it this line that is causing the problem?
Edit the question with the files/folders you did commit to SVN.
Additionally, make sure to setup your PC/Mac to display hidden files and folders and see that you did not miss those.
Specifically, there is a .settings folder (. denotes a hidden folder in Mac) that also contains a org.eclipse.core.resources.prefs file.
I'd be interested to see the result of an import of a project that does contain this folder and this specific file.

Use eclipse as svn client

Running OSX.
I have used eclipse for years as a Java developer. I am now messing with all kinds of new technologies but still find myself using svn (don't ask its not my descision). Anyways I don't really like SVN command line as I find it almost impossible to sort through merge conflicts.
With that I was thinking about using eclipse (w/ subclipse plugin) as my SVN client whenever I need to do SVN type things. The one problem that I have found is that eclipse loves to create a .project file. I would never want to check this in as no one else is using eclipse. I know that I can add it to svn:ignore, but that has to actually commit that ignore to SVN as well, which I do not want to do either.
Anyway to create eclipse projects without the .project file. I know sounds dumb because I am sure that eclipse needs the .project file for all its projects. Would be nice just to create an SVN project (not Java project) and have eclipse leave off any other crap.
ideas?
There is no way to create an Eclipse project without the .project file (at least none that I know of), but you can tell Eclipse which files to ignore, as well.
Just go to Preferences -> Team -> Ignored Resources and add the pattern .project.
This setting is purely Eclipse-internal and does neither affect your global svn-ignores (defined in ~/.subversion/config) nor will it add any files to the repository.
Also, when checking out folders from SVN using Eclipse, make sure to create a General Project, not a Java Project, so the .project file is the only file Eclipse creates.
.project is actually not the only file that will be generated - depending on the "project natures" you add to a project.
To really separate the project from the source folders, you'll have to create the project in a separate folder - say the workspace - remove the original source folder and add the source folders as external links - see: Project Settings/Java Build Path/Source.

eclipse - building projects dependent on jars - created during ant

I am experiencing a problem with Eclipse's building its projects.
The procedure for setting a dev env is:
Creating a clearcase view.
Opening eclipse.
Importing preferences.
Connecting to clearcase plugin.
Importing a team-set.
Running ant - build.xml
During the build.xml, some files are generated and moved from its working directory into the some projects' lib directories.
After that, there are some eclipse.referesh task and eclipse.incrementalBuild that the build.xml invokes.
Now, the projects the jars (generated during build.xml) were copied into, do get compiled successfully, but other projects depending on them do not.
Even if I try refreshing the entire workspace and clean-building all of its projects manually, this doesn't work.
The problem is resolved only when I close the projects and open them (an eclipse feature).
It is possible that this is happening due to the ClearCase plugin?
Anyway on how to resolve this problem (It causes the build.xml to fail, because of compiler problems)?
With the official IBM ClearCase Eclipse plugin (presented in "What Clearcase eclipse-plugin to use in order to work on both clearcase 6 and 7 projects?"), I don't have that kind of issue if:
the .project and .classpath are within the ClearCase view, alongside the versioned sources
(see "Clearcase plugin for eclipse usage")
In other words, all files (eclipse files, ant files, ...) should be parth of the project directory, outside of the eclipse workspace itself (said eclipse workspace contains only a reference to the project, none of the actual files part of a ClearCase views, and located elsewhere, where the CC view actually is)
If you respect that organization, then the ClearCase plugin should have 0 effect on what your project are doing.