I have an instance of crafter running with crafter-studio-publishing-receiver-2.5.3-aio.jar, I need to locate the source code for the jar file.
Is this the right repository
What is the significance of the word "legacy" in the name of the project?
You can find the source code here:
https://github.com/craftercms/legacy-deployer
The specific version can be found by checking the manifest of the jar.
- unzip the jar
- open ./META-INF/MANIFEST.MF
- locate the property Implementation-Build: 87c84d58313b2bcbdca306de69758320aee174d0
This value can be placed in github to get the exact code you are looking for.
Example:
https://github.com/craftercms/legacy-deployer/blob/87c84d58313b2bcbdca306de69758320aee174d0/cstudio-publishing-receiver-zip/pom.xml
The reason we renamed the project "legacy-deployer" in github is that with Crafter 3.x we are moving to a new deployment system. Without going too deep on this: The new system is based on Git pulls, as you can imagine, this approach has many benefits. It will support the same concepts (callbacks etc) as the now "legacy" deployer.
Related
In 10 minutes, I created an empty android library and an empty android application in this git repository
https://github.com/deanhiller/compositeAndroid
As seen in my last commit, I quickly convert the android application do depend on the library via gradle's awesome composite build feature (We use this feature a TON in our monorepo so loading a project loads all the libraries source code that it uses as well). Our library is shared amongst a few projects.
I cd into compositeAndroid/MyApplication and run ./gradlew build and it fails with
* What went wrong:
Could not determine the dependencies of task ':app:mergeReleaseAssets'.
> Could not resolve all task dependencies for configuration ':app:releaseRuntimeClasspath'.
> Could not resolve com.tray.android:MyLib.
Required by:
project :app
> No matching configuration of project :MyLib was found. The consumer was configured to find a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.0' but:
- None of the consumable configurations have attributes.
I am not sure how to work around this. I have a work around to publish/consume but would much prefer composite builds as it brings the source of libraries into intellij cleanly.
Why is composite builds not working? Is there something special I have to do for android projects? The above repo I setup in 10 minutes with those 2 projects(brand new).
You can always clone and play with it yourself as well. (We will actually be releasing our monorepo open-source template however it is not working to well with android just yet).
After looking into the code under MyLib folder in the repository you shared here - it seems you've opened a regular project and intend to use it as a library
Can you please follow the steps required here and test it under a new module?
Hint: your build should result with an aar file
We are looking for solution to export the data to excel in Vaadin application.
I have downloaded Vaadin excel exporter from GitHub https://github.com/bonprix/vaadin-excel-exporter which sounds to be a very useful utility but I am getting the error below when I am compiling vaadin-excel-exporter-demo project.
<vaadin.version>8.0.6</vaadin.version>
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project vaadin-excel-exporter-demo: Compilation failure: Compilation failure:
[ERROR] /C:/Java/Vaadin/VaadinProjetcs/vaadin-excel-exporter-master/vaadin-excel-exporter-master/vaadin-excel-exporter-demo/src/main/java/org/vaadin/addons/excelexporter/demo/DemoUI.java:[12,61] package org.vaadin.addons.excelexporter.configuration.builder does not exist
I've tried mvn clean and also delete the full .m2/repository local repository
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
After searching on different forums it looks like maybe this add-on is missing from Maven repo. I have tried version 2.1 and LATEST.
<artifactId>vaadin-excel-exporter</artifactId>
<packaging>jar</packaging>
<!--version>2.1-SNAPSHOT</version-->
<version>LATEST</version>
<name>Excel Exporter</name>
So I have two questions.
Has anybody had the same problem wih this tool and/or maybe can explain what i am doing wrong.
If this tool is not maybe available anymore can anyone please share the tool which I can use to export the grid data to Excel. I am new with Vaadin so providing the code examples will be highly appreciated
Thanks
Alex
If you look at the add-on through Vaadin directory, you'll find the necessary additions to your pom.xml in the Maven section of the sidebar. In this case, like Erik said in the comments, you are likely missing
<repository>
<id>vaadin-addons</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
</repository>
The directory page also includes code samples for using the component after you get the dependencies fixed, as well as other information about the add-on. I haven't tested whether the demo within GitHub works, but the add-on itself should be usable in your project regardless. The newest version published through the directory is 2.0.
If you want to compile the add-on locally rather than use it through the add-on repository, you need to first successfully compile the add-on module, and then use the exact version configured in the pom.xml. Currently the master branch seems to be using <version>2.1-SNAPSHOT</version>.
Is there any easy way how to show a library version used in project in giltab README.md / badge, parsed directly from repository source code? I mean something automatic, I do not want to increase version in readme everytime it is changed in the source code.
There is no built-in solution (open issue on GitLab)
My suggestion is to build your own script that reads the property from the source code, and replace it on your README.md file.
You can run this script as a job on your "release/deploy" stage.
P.S.
It's best to handle the versions using git-tag and not the source code itself.
I’m on a .net c# project composed by a solution with several class library projects.
The source control is managed by git using gitflow as branching model.
We have decided that we wanted to implement semantic versioning (http://semver.org/) of the project in order to follow a standard way to communicate our releases.
For that we are using GitVersionTask (via NuGet) which works pretty well with gitflow.
Every time we tag a release and we perform a build from the master branch the version of all assemblies are updated and a new release is out for delivery.
Only one of the assemblies has a public API, all the other are for internal consume. I would like to know if this is the correct way to manage the version of multiple assemblies of the same project I mean, isn’t it wrong to change the version of every assembly when only a couple (or even just one) was changed? To get thinks more complicated there is strong possibility that some of the “internal” assemblies will be used by other projects so I believe it not very wise to increment a major version of an assembly that didn’t suffer a change just because another assembly of the same project is promoting breaking changes. Should each assembly project be managed on its own repository?
Thanks in advance.
I know this is a bit of an old question, still:
I want to share a workaround that seems to be working:
GitVersion uses $(Build.SourcesDirectory) to see where the sources are located - src
We can change this using logging commands*
Workaround is to set the Build.SourcesDirectory before GitVersion task
Then gitVersion uses the GitVersion.yml from the project folder (Build.SourceDirectory) and voila - works
After that you might want to roll back the change or not - depending on your need. For me it seems it is nice to scope down to the only nuget package from the collection of nuget packages in our nugetPackages monorepo.
see GitVersion issue and comment
*Example Powershell command:
standard PowerShell task; set to inline script;
Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$(Build.SourcesDirectory)\$(NugetProjectName)"
There is certainly nothing in GitVersion that would help with having separate projects within the same repository. The guidance that we would offer here is that you should use different repositories for the different parts of your application. That way they can be versioned/updated at their own cadence.
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.