Используя Знатока для проекта Coldfusion

Все это зависит от приложения. Генератор, который создает "большинство случайных" чисел, не мог бы быть самым быстрым или самым эффективным памятью, например.

вихрь Мерсенна алгоритм является популярным, довольно быстрым генератором псевдослучайного числа, который приводит к довольно хорошим результатам. Это имеет огромно большой период, но также и относительно огромное состояние (2,5 КБ). Однако это не считают достаточно хорошим для криптографических приложений.

Обновление : Так как этот ответ был записан, , семейство PCG алгоритмов было опубликовано, который, кажется, превосходит существующие некриптографические алгоритмы по характеристикам для большинства передних сторон (скорость, память, случайность и период), делая это превосходным всесторонним выбором для чего-либо , но криптография .

, Если Вы делаете crypto, хотя, мой ответ остается: не прокручивайте свое собственное.

9
задан Nightfirecat 5 October 2011 в 18:09
поделиться

2 ответа

Во-первых, вот еще один блог, который может оказаться полезным.

build-tools-maven-and-coldfusion

Я не пробовал создавать ColdFusion с Maven, но у меня есть опыт управления сборками Maven для крупной компании. Вы должны учесть несколько моментов.

Структура проекта

Файлы cfm и cfc Coldfusion должны быть помещены в src / main / resources, чтобы они были объединены в jar (упомянутый выше блог отменяет соглашение Maven о размещении их в src. это нормально, но это может стать проблемой, если вам позже понадобится добавить что-нибудь еще в проект).

Я бы, вероятно, сохранил файлы cfc и cfm в отдельных проектах с соответствующими объявлениями зависимостей для их связывания, это сохраняет ваши проекты cfc как библиотеки и помогает повторное использование. Также стоит учитывать степень детализации проектов cfc. Как правило, управление зависимостями Maven помогает сохранить небольшие артефакты, не беспокоясь об обнаружении всех jar-файлов.

Развертывание

Самый простой способ доставить артефакты - использовать maven-war-plugin чтобы создать войну, содержащую ваши артефакты и все их транзитивные зависимости. Это делает каждое приложение самодостаточным, что может быть полезно. Обратной стороной этого является то, что вам придется многократно объединять одни и те же артефакты, и они могут быть довольно большими. Чтобы смягчить это, вы можете либо использовать подключаемый модуль сборки для создания собственных пакетов, исключая общие компоненты, либо указать, что определенные компоненты (например, ColdSpring) являются областью , предоставленной , это означает, что они не будут включены в войну.

Управление версиями

Maven поощряет распространение зависимостей, по умолчанию у каждого объявления зависимости есть версия, это может вызвать проблемы с обслуживанием, особенно когда вы хотите поднять версию внешнего зависимость. Вы можете смягчить это, определив родительский POM или POM «приложения». Любой из них будет иметь раздел dependencyManagement, в котором объявляются сведения (groupId, artifactId и версия) для общих артефактов. Любой POM, унаследованный от родителя, не должен объявлять версию зависимости, поскольку он будет унаследован (обратите внимание, что это не t означает, что все дочерние элементы будут иметь все зависимости, только те, которые объявляют зависимость, не должны объявлять версию). Если вы определяете проект «app» с упаковкой «pom» и разделом dependencyManagement, вы можете ссылаться на него с помощью scope import (начиная с Maven 2.0.9 и далее), это импортирует раздел dependencyManagement из приложения «Проект к проекту ПОМ. Дополнительные сведения см. В документации по зависимостям .

Если вы объявляете зависимость с областью действия в разделе dependencyManagement, эта область будет унаследована, если она не будет переопределена в дочернем POM. Относительно раздела развертывания выше, это означает, что вы можете объявить область общих библиотек , предоставленную в родительском компоненте, чтобы гарантировать, что они не связаны в каждом приложении. Вам понадобится соглашение об именах для пакетов, чтобы избежать конфликтов. Вероятно, лучше всего следовать соглашению Maven и использовать групповые идентификаторы Java-пакета (org.apache.maven для maven.apache.org) и имя jar-файла для артефакта. В соответствии с этим соглашением groupId будет «org.coldspringframework» и artifactId «coldspring» для ColdSpring.

Возможно, потребуется провести дополнительные различия в компании. Например, если у вас есть веб-группа и основная группа, вы можете дать веб-группе идентификаторы groupIds com.mycompany.web. * И основной группы com.mycompany.core. *

Dependency Management

. для добавления ваших пакетов CFC в репозиторий Maven, например Nexus , чтобы они были доступны для других сборок на предприятии.

Если вы хотите хранить пакеты CFC отдельно от jar-файлов. Вы можете указать собственный тип упаковки, чтобы они выиграли ' нельзя путать с какими-либо артефактами Java. Если вы создаете собственный тип упаковки, артефакты могут иметь расширение «.jar», но для любого объявления зависимостей должен быть установлен тип.

Вот пример, следующий этим соглашениям:

<dependency>
  <groupId>org.coldspringframework</groupId>
  <artifactId>coldspring</artifactId>
  <version>1.2</version>
  <!--custom packaging type helps keep separate from Java artifacts-->
  <type>cfc</type>
</dependency>

В книге Nexus есть раздел, который описывает пользовательские жизненные циклы (для получения более подробной информации перейдите по ссылкам. По сути, вам нужно создать плагин с META-INf / plexus / components.xml, чтобы описать механизм сплетения (какой архиватор использовать, какое расширение выводить и т. д.).

Файл components.xml будет выглядеть примерно так:

<component-set>
  <components>
    <component>
      <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
      <role-hint>cfc</role-hint>
      <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
      <configuration>
        <phases>
          <process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
          <package>com.hsbc.maven.plugins:maven-jar-plugin:jar</package>          
          <install>org.apache.maven.plugins:maven-install-plugin:install</install>
          <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
        </phases>
      </configuration>
    </component>
    <component>
      <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
      <role-hint>cfc</role-hint>
      <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
      <configuration>
        <extension>jar</extension>
        <type>cfc</type>
        <packaging>cfc</packaging>
      </configuration>
    </component>
     <component>
       <role>org.codehaus.plexus.archiver.Archiver</role>
       <role-hint>cfc</role-hint>
       <implementation>org.codehaus.plexus.archiver.zip.ZipArchiver</implementation>
       <instantiation-strategy>per-lookup</instantiation-strategy>
     </component>
     <component>
       <role>org.codehaus.plexus.archiver.UnArchiver</role>
       <role-hint>cfc</role-hint>
       <implementation>org.codehaus.plexus.archiver.zip.ZipUnArchiver</implementation>
       <instantiation-strategy>per-lookup</instantiation-strategy>
     </component>
  </components>
</component-set>
13
ответ дан 4 December 2019 в 15:22
поделиться

Maven мне тоже показался интересным, но я не мог найти достаточно ресурсов, и у меня не было достаточно времени, чтобы разобраться в этом, поэтому я перешел на то, что казалось хорошим.

Насколько я понимаю, вы предпочитаете использовать Maven, я наткнулся на несколько статей о Ant и Coldfusion, а также недавнюю статью о Hudson с Coldfusion.

В Coldfusion также есть тег cfant (недокументированный). Вы можете запускать сценарии ANT прямо из CF?

0
ответ дан 4 December 2019 в 15:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: