Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I have a dependency, actually two dependencies to which I'd like to make changes either right now like fixing JBSEAM-3424 or potentially in the future. The coding is not an issue - I'm capable of making the change - and I'm not seeking to fork the community project, just to have a local version as recommended by Will Hartung to get some work done.
My concern is that issues of process will come up and bite me further down the line. So SO what can I do to ensure I manage this properly. What best practices are there?
Some more specific sub-questions:
Should I change the artifact names?
How choose group artifact and
version names?
Should I import the whole source tree
or be selective?
What if I can't get the build system
working in full - should I scale it
down or try to keep it close to the
original?
Should I change the artifact names?
How choose group artifact and version names?
Keep the groupId and artifactId of the module(s) you change the same, but use a qualifier on the version to ensure that it is obvious it is a non-standard version, for example 1.0.0-simon. This is pretty common practice.
Should I import the whole source tree or be selective?
Update based on your comment: Personally I'd only add the artifacts I've changed to my local source repository. If you change another artifact later then add it to your SCM then.
What if I can't get the build system working in full
Worry about that when it happens. If the project is built with Maven it should be straightforward for you to build only the artifacts you need. If it uses an uber-ant build which you can't get working with your changes, then consider paring the build down.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 days ago.
Improve this question
For a some time now I'm thinking about a way to setup a continuous delivery pipeline and don't seem to get my head around it.
I want to auto-create a Github release with a corresponding tag. Plus I want to update the version in a file inside the repo (/docs/antora.yml). The version in the antora.yml should be the same as the tag which I want to create.
Since the source of truth always is the main branch on Github I only want to create tags in the remote repo. Tagging locally and pushing the tag to the remote repo is not an options! Ideally I would like a successful Pull Request to be the trigger. But (as far as I understand) then I always have to create a branch. Plus I don't want every PR into main to create a new release and tag. I want to handpick the PRs.
One way to achieve this would be to create a dedicated release/v1.2.3 branch, run everything from there and auto-create a tag and release. Then a release pipeline could listen to the tag-creation and do the actual e.g. deployment to DockerHub.
What I don't like about this is, that I need a release-branch which kind of moves me further away from working trunk-based. And I need two pipelines: a CD-pipeline which would only handle organizational stuff and a release-pipeline which does the technical deployments.
I would prefer to do everything in a single CD pipeline based on the main branch.
Now I'm very interested in your opinions. Are my thoughts valid or is this some kind of anti-pattern? Do you know some best practices? Maybe someone has an example implementation? I think I can handle writing the actual pipeline code. I'm just not sure how to organize my process. By the way: I already have a CI pipeline working. So to me CD is the logical next step
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
If your goal were to botch a legacy application modernization project, how would you set about it?
What are the worst strategies and practices to adopt?
Port it to node.js and bury it deep in dependencies on single-maintainer abandoned packages, many layers deep and interconnected, so that it'll be essentially a total re-write to get rid of those dependencies 2-3 years down the road when some update to some tiny package somewhere at the end of a long dependency chain breaks everything and introduces impossible version requirements (aka package A wants the new version of package X, but package B is locked to the old version, while package C is fine with the old and newer versions, but not the newest. It has announced to drop compatability with the old version in the next update...)
There's a few other languages where that would probably work as well.
The strategy behind that is to use fragmentation as a weapon against the poor sod who'll have to maintain and update that monster. If you make the dependency graph silly enough, sooner or later something will break in terrible ways.
Another aspect of bad practice is when people are mixing their front-end project with both .scss, .css, .ts and .js because they sometimes just don't find a solution of some case in TypeScript they implement JavaScript files in the same project. Then there are many cases where people implement poor JavaScript libraries in TypeScript projects that do not support TypeScript and will break the application now or later.
Some other bad practice is to not organize your .js files and write more and more code in a single .js file that will reach 1000 rows then 2000 rows etc.. and after a while, there is no point updating anything in that file because its impossible to get the whole picture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm new on diving in the OSGi world.
I'm trying to develop an application with the following modules(bundles):
model
services-api
default-services
web
Suppose the default-service bundle contains internal data access services.Therefore, it needs
some configuration for the database access.
It doesn't feel right to me to place the DB configuration within the default-services bundle.
Also, the web bundle should not know how the default-service is internally wired.
My question is: Does OSGi have a concept of configuration bundle? My idea was to deploy a bundle responsible for the default-service configuration. Is there a similar solution for that?
Have you looked at ConfigurationAdmin service? Your bundles should use ConfigurationAdmin to receive their configuration. If you use Declarative Services in your bundles, DS will automate the use of ConfigurationAdmin for you.
Depending on how you expect to do configuration, fragments may suit your needs. They allow you to add extra information to the existing bundles classpath. We use this to provide different configurations for different runtime environments (dev, test, ...). You simply deploy the appropriate fragment bundle to have the correct configuration.
I actually developed a little bundle that can detect configuration data in other bundles with the extender pattern. In my case this is a Jason file. Got some special tricks to handle passwords and binary files like ssl certificates.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I browsed some of their sites. They always point to bug list as start of participating project.But, as a newbie in that project? How can I fix bug at the beginning?
Can anybody give me some suggestions about this?
Issac Truett's answer is good.
My only suggestion would be to pick a project and download their source code. Most open source projects use CVS, Subversion, or Git to manage the source code.
Pick an integrated development environment (IDE) that supports the language of the project and attach the IDE to their source code manager.
Spend some time getting familiar with the source code, and the bug list will make more sense.
Almost every Open Source project I've ever seen has a stack of minor issues in the corner - cosmetic or otherwise largely inconsequential things that nobody has considered worth their time. If you just want to get your foot in the door, that's probably a good way to introduce yourself. Just find something easy, make sure you implement it well, and follow the project's rules on coding style, submission for review, etc.
Or, ask the project. "I'm new, I want to help, this is my skill set. Would someone be willing to mentor me?"
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm intending to use the Ms-RL for a project on CodePlex, but I'm not sure how far I should go in terms of how I actually use / embed it in the solution.
Simply including the full licence text somewhere in each project is a given, as is appropriate usage in the project properties / assembly meta-tags; but would you go so far as to include the full licence or (more likely) a short statement pointing to the full licence) at the head of every file?
FYI - The complete solution contains an ASP.NET web project and about 6 'normal' class based projects.
You Could just include one file in a folder or somewhere called License.txt which contains the Ms-RL
But thats realy not a programming question. The admin should (must) close this question
In the end I took the GNU GPL type approach:
A copy of the full licence text with each project (licence.txt).
A 'reference' to the licence file (as well as a small blurb) at the top of each code file.
Of course, throwing a bit of text in the top of each code file might be a simple concept but its not a trivial thing to do if you have multiple projects and files. So in the end I whipped up a small tool to do it for me.
Get it here: http://www.morphological.geek.nz/MorphologicalLicenceInserter/default.aspx (99Kb, full source code, released under Ms-RL).
How to use it:
Copy your code to a staging area (I use RoboCopy).
Crank up the Licence Inserter Tool and have it 'embed' a bit of text (which you write once) into the top of every file you want the reference to appear in.
Check or test the end result of the licence embedding process, and you're good to go.
The program automatically 'wraps' your text in the correct commenting syntax for the file type.