You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <dk...@gmail.com> on 2010/11/03 19:21:48 UTC

slight change to way of doing build and site

Dear all,

As you know, our trunk/pom.xml currently has a set of profiles that us 
to perform builds of different "widths" (ie which modules), different 
"depths" (just the minimum, or full javadocs, reports etc), and 
different types (default lifecycle vs site lifecycle).  As things are, 
we use -P and a comma separated list to activate multiple profiles, eg 
-P all,build-all.

However, I've been looking at the release process that we've inherited 
from the ASF parent, and it looks like this approach of using -P is 
incompatible.  So, I've used the very similar mechanism of activating 
profiles by specifying a -D property.

Basically, to activate profile with id xxx-yyy, instead of -P xxx-yyy, 
you use -D xxx=yyy

~~~~
Therefore, the new ways to build are:

mvn clean install -o                                          # the 
modules-standard profile is activated by default
mvn clean install -D modules=standard -o    # explicitly activating the 
modules-standard profile
mvn clean install -D build=full -o                    # modules-standard 
and also the build-full profile
mvn clean install -D modules=all -o               # explicitly 
activating modules-all profile
mvn clean install -D modules=all -D build=full -o   # explicitly 
activating both modules-all and build-full


To build the site docs:

prereqs are pretty much as before:
a) mvn install:install-file -D groupId=com.java -D artifactId=jimi  -D 
version=1.0 -D packaging=jar -D file=/path/to/file
b) mvn clean install -D modules=skin -o     # explicitly activate the 
modules-skin profile

and then:
mvn site-deploy -D modules=standard -D deploy=local 
-o                     # activate modules-standard and deploy-local profile
mvn site-deploy -D modules=standard -D deploy=local -D site=full -o  # 
activate modules-standard,deploy-local, site-full


~~~~
All the above is also documented in trunk/pom.xml, which I've just this 
minute committed (rev 1030591).

Thx
Dan


Re: slight change to way of doing build and site

Posted by dan haywood <da...@haywood-associates.co.uk>.
If you use -D site=full, then it'll build the docbooks and other reports.
Otherwise it'll just build the minimum.

Dan

On 14 November 2010 11:00, Mohammad Nour El-Din <no...@gmail.com>wrote:

> Yes, but will docbkx-maven-plugin work JAI ? Also I didn't install
> JIMI to my machine but I could build Apache Isis site which means that
> there is something not generated properly, right ?
>
> On Sun, Nov 14, 2010 at 8:44 AM, Dan Haywood <dk...@gmail.com> wrote:
> > Hi Nour,
> > I think it's a case of, "if it ain't broke, don't fix it".  It's needed
> as a
> > prereq for docbkx-maven-plugin in order to embed images in our PDF docs.
> >
> > It's annoying, I admit, to have to install the JIMI file manually.  But
> from
> > a quick google it looks like JAI would also need to be installed
> manually.
> >
> > I had a quick google, and found the same issue mentioned in the parent
> POM
> > for OpenJPA [1] (nb: OpenJPA is one of Mark's projects).
> >
> > I couldn't find anything to say that jimi has been deprecated, but if you
> > want to raise a JIRA ticket re: moving to JAI instead, be my guest.  It
> > might be very simple to do (see [1]).
> >
> > Cheers
> > Dan
> >
> > [1]
> >
> http://svn.apache.org/repos/asf/openjpa/sandboxes/osgi/openjpa-project/pom.xml
> >
> >
> > On 13/11/2010 13:31, Mohammad Nour El-Din wrote:
> >>
> >> Hey Dan...
> >>
> >>    According to [1] Jimi is for Java 1.x which is too old. Why we
> >> still using it ? and what is the effort estimate IUO to move to Java 2
> >> Imaging API(s) ?
> >>
> >> [1] - http://java.sun.com/products/jimi/
> >>
> >> On Wed, Nov 3, 2010 at 6:21 PM, Dan Haywood<dk...@gmail.com>
>  wrote:
> >>>
> >>> Dear all,
> >>>
> >>> As you know, our trunk/pom.xml currently has a set of profiles that us
> to
> >>> perform builds of different "widths" (ie which modules), different
> >>> "depths"
> >>> (just the minimum, or full javadocs, reports etc), and different types
> >>> (default lifecycle vs site lifecycle).  As things are, we use -P and a
> >>> comma
> >>> separated list to activate multiple profiles, eg -P all,build-all.
> >>>
> >>> However, I've been looking at the release process that we've inherited
> >>> from
> >>> the ASF parent, and it looks like this approach of using -P is
> >>> incompatible.
> >>>  So, I've used the very similar mechanism of activating profiles by
> >>> specifying a -D property.
> >>>
> >>> Basically, to activate profile with id xxx-yyy, instead of -P xxx-yyy,
> >>> you
> >>> use -D xxx=yyy
> >>>
> >>> ~~~~
> >>> Therefore, the new ways to build are:
> >>>
> >>> mvn clean install -o                                          # the
> >>> modules-standard profile is activated by default
> >>> mvn clean install -D modules=standard -o    # explicitly activating the
> >>> modules-standard profile
> >>> mvn clean install -D build=full -o                    #
> modules-standard
> >>> and
> >>> also the build-full profile
> >>> mvn clean install -D modules=all -o               # explicitly
> activating
> >>> modules-all profile
> >>> mvn clean install -D modules=all -D build=full -o   # explicitly
> >>> activating
> >>> both modules-all and build-full
> >>>
> >>>
> >>> To build the site docs:
> >>>
> >>> prereqs are pretty much as before:
> >>> a) mvn install:install-file -D groupId=com.java -D artifactId=jimi  -D
> >>> version=1.0 -D packaging=jar -D file=/path/to/file
> >>> b) mvn clean install -D modules=skin -o     # explicitly activate the
> >>> modules-skin profile
> >>>
> >>> and then:
> >>> mvn site-deploy -D modules=standard -D deploy=local -o
> >>>   #
> >>> activate modules-standard and deploy-local profile
> >>> mvn site-deploy -D modules=standard -D deploy=local -D site=full -o  #
> >>> activate modules-standard,deploy-local, site-full
> >>>
> >>>
> >>> ~~~~
> >>> All the above is also documented in trunk/pom.xml, which I've just this
> >>> minute committed (rev 1030591).
> >>>
> >>> Thx
> >>> Dan
> >>>
> >>>
> >>
> >>
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
>   Author of (WebSphere Application Server Community Edition 2.0 User Guide)
>   http://www.redbooks.ibm.com/abstracts/sg247585.html
> - LinkedIn: http://www.linkedin.com/in/mnour
> - Blog: http://tadabborat.blogspot.com
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
> "Writing clean code is what you must do in order to call yourself a
> professional. There is no reasonable excuse for doing anything less
> than your best."
> - Clean Code: A Handbook of Agile Software Craftsmanship
>
> "Stay hungry, stay foolish."
> - Steve Jobs
>

Re: slight change to way of doing build and site

Posted by Mohammad Nour El-Din <no...@gmail.com>.
Yes, but will docbkx-maven-plugin work JAI ? Also I didn't install
JIMI to my machine but I could build Apache Isis site which means that
there is something not generated properly, right ?

On Sun, Nov 14, 2010 at 8:44 AM, Dan Haywood <dk...@gmail.com> wrote:
> Hi Nour,
> I think it's a case of, "if it ain't broke, don't fix it".  It's needed as a
> prereq for docbkx-maven-plugin in order to embed images in our PDF docs.
>
> It's annoying, I admit, to have to install the JIMI file manually.  But from
> a quick google it looks like JAI would also need to be installed manually.
>
> I had a quick google, and found the same issue mentioned in the parent POM
> for OpenJPA [1] (nb: OpenJPA is one of Mark's projects).
>
> I couldn't find anything to say that jimi has been deprecated, but if you
> want to raise a JIRA ticket re: moving to JAI instead, be my guest.  It
> might be very simple to do (see [1]).
>
> Cheers
> Dan
>
> [1]
> http://svn.apache.org/repos/asf/openjpa/sandboxes/osgi/openjpa-project/pom.xml
>
>
> On 13/11/2010 13:31, Mohammad Nour El-Din wrote:
>>
>> Hey Dan...
>>
>>    According to [1] Jimi is for Java 1.x which is too old. Why we
>> still using it ? and what is the effort estimate IUO to move to Java 2
>> Imaging API(s) ?
>>
>> [1] - http://java.sun.com/products/jimi/
>>
>> On Wed, Nov 3, 2010 at 6:21 PM, Dan Haywood<dk...@gmail.com>  wrote:
>>>
>>> Dear all,
>>>
>>> As you know, our trunk/pom.xml currently has a set of profiles that us to
>>> perform builds of different "widths" (ie which modules), different
>>> "depths"
>>> (just the minimum, or full javadocs, reports etc), and different types
>>> (default lifecycle vs site lifecycle).  As things are, we use -P and a
>>> comma
>>> separated list to activate multiple profiles, eg -P all,build-all.
>>>
>>> However, I've been looking at the release process that we've inherited
>>> from
>>> the ASF parent, and it looks like this approach of using -P is
>>> incompatible.
>>>  So, I've used the very similar mechanism of activating profiles by
>>> specifying a -D property.
>>>
>>> Basically, to activate profile with id xxx-yyy, instead of -P xxx-yyy,
>>> you
>>> use -D xxx=yyy
>>>
>>> ~~~~
>>> Therefore, the new ways to build are:
>>>
>>> mvn clean install -o                                          # the
>>> modules-standard profile is activated by default
>>> mvn clean install -D modules=standard -o    # explicitly activating the
>>> modules-standard profile
>>> mvn clean install -D build=full -o                    # modules-standard
>>> and
>>> also the build-full profile
>>> mvn clean install -D modules=all -o               # explicitly activating
>>> modules-all profile
>>> mvn clean install -D modules=all -D build=full -o   # explicitly
>>> activating
>>> both modules-all and build-full
>>>
>>>
>>> To build the site docs:
>>>
>>> prereqs are pretty much as before:
>>> a) mvn install:install-file -D groupId=com.java -D artifactId=jimi  -D
>>> version=1.0 -D packaging=jar -D file=/path/to/file
>>> b) mvn clean install -D modules=skin -o     # explicitly activate the
>>> modules-skin profile
>>>
>>> and then:
>>> mvn site-deploy -D modules=standard -D deploy=local -o
>>>   #
>>> activate modules-standard and deploy-local profile
>>> mvn site-deploy -D modules=standard -D deploy=local -D site=full -o  #
>>> activate modules-standard,deploy-local, site-full
>>>
>>>
>>> ~~~~
>>> All the above is also documented in trunk/pom.xml, which I've just this
>>> minute committed (rev 1030591).
>>>
>>> Thx
>>> Dan
>>>
>>>
>>
>>
>



-- 
Thanks
- Mohammad Nour
  Author of (WebSphere Application Server Community Edition 2.0 User Guide)
  http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

"Stay hungry, stay foolish."
- Steve Jobs

Re: slight change to way of doing build and site

Posted by Dan Haywood <dk...@gmail.com>.
Hi Nour,
I think it's a case of, "if it ain't broke, don't fix it".  It's needed 
as a prereq for docbkx-maven-plugin in order to embed images in our PDF 
docs.

It's annoying, I admit, to have to install the JIMI file manually.  But 
from a quick google it looks like JAI would also need to be installed 
manually.

I had a quick google, and found the same issue mentioned in the parent 
POM for OpenJPA [1] (nb: OpenJPA is one of Mark's projects).

I couldn't find anything to say that jimi has been deprecated, but if 
you want to raise a JIRA ticket re: moving to JAI instead, be my guest.  
It might be very simple to do (see [1]).

Cheers
Dan

[1] 
http://svn.apache.org/repos/asf/openjpa/sandboxes/osgi/openjpa-project/pom.xml


On 13/11/2010 13:31, Mohammad Nour El-Din wrote:
> Hey Dan...
>
>     According to [1] Jimi is for Java 1.x which is too old. Why we
> still using it ? and what is the effort estimate IUO to move to Java 2
> Imaging API(s) ?
>
> [1] - http://java.sun.com/products/jimi/
>
> On Wed, Nov 3, 2010 at 6:21 PM, Dan Haywood<dk...@gmail.com>  wrote:
>> Dear all,
>>
>> As you know, our trunk/pom.xml currently has a set of profiles that us to
>> perform builds of different "widths" (ie which modules), different "depths"
>> (just the minimum, or full javadocs, reports etc), and different types
>> (default lifecycle vs site lifecycle).  As things are, we use -P and a comma
>> separated list to activate multiple profiles, eg -P all,build-all.
>>
>> However, I've been looking at the release process that we've inherited from
>> the ASF parent, and it looks like this approach of using -P is incompatible.
>>   So, I've used the very similar mechanism of activating profiles by
>> specifying a -D property.
>>
>> Basically, to activate profile with id xxx-yyy, instead of -P xxx-yyy, you
>> use -D xxx=yyy
>>
>> ~~~~
>> Therefore, the new ways to build are:
>>
>> mvn clean install -o                                          # the
>> modules-standard profile is activated by default
>> mvn clean install -D modules=standard -o    # explicitly activating the
>> modules-standard profile
>> mvn clean install -D build=full -o                    # modules-standard and
>> also the build-full profile
>> mvn clean install -D modules=all -o               # explicitly activating
>> modules-all profile
>> mvn clean install -D modules=all -D build=full -o   # explicitly activating
>> both modules-all and build-full
>>
>>
>> To build the site docs:
>>
>> prereqs are pretty much as before:
>> a) mvn install:install-file -D groupId=com.java -D artifactId=jimi  -D
>> version=1.0 -D packaging=jar -D file=/path/to/file
>> b) mvn clean install -D modules=skin -o     # explicitly activate the
>> modules-skin profile
>>
>> and then:
>> mvn site-deploy -D modules=standard -D deploy=local -o                     #
>> activate modules-standard and deploy-local profile
>> mvn site-deploy -D modules=standard -D deploy=local -D site=full -o  #
>> activate modules-standard,deploy-local, site-full
>>
>>
>> ~~~~
>> All the above is also documented in trunk/pom.xml, which I've just this
>> minute committed (rev 1030591).
>>
>> Thx
>> Dan
>>
>>
>
>

Re: slight change to way of doing build and site

Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hey Dan...

   According to [1] Jimi is for Java 1.x which is too old. Why we
still using it ? and what is the effort estimate IUO to move to Java 2
Imaging API(s) ?

[1] - http://java.sun.com/products/jimi/

On Wed, Nov 3, 2010 at 6:21 PM, Dan Haywood <dk...@gmail.com> wrote:
> Dear all,
>
> As you know, our trunk/pom.xml currently has a set of profiles that us to
> perform builds of different "widths" (ie which modules), different "depths"
> (just the minimum, or full javadocs, reports etc), and different types
> (default lifecycle vs site lifecycle).  As things are, we use -P and a comma
> separated list to activate multiple profiles, eg -P all,build-all.
>
> However, I've been looking at the release process that we've inherited from
> the ASF parent, and it looks like this approach of using -P is incompatible.
>  So, I've used the very similar mechanism of activating profiles by
> specifying a -D property.
>
> Basically, to activate profile with id xxx-yyy, instead of -P xxx-yyy, you
> use -D xxx=yyy
>
> ~~~~
> Therefore, the new ways to build are:
>
> mvn clean install -o                                          # the
> modules-standard profile is activated by default
> mvn clean install -D modules=standard -o    # explicitly activating the
> modules-standard profile
> mvn clean install -D build=full -o                    # modules-standard and
> also the build-full profile
> mvn clean install -D modules=all -o               # explicitly activating
> modules-all profile
> mvn clean install -D modules=all -D build=full -o   # explicitly activating
> both modules-all and build-full
>
>
> To build the site docs:
>
> prereqs are pretty much as before:
> a) mvn install:install-file -D groupId=com.java -D artifactId=jimi  -D
> version=1.0 -D packaging=jar -D file=/path/to/file
> b) mvn clean install -D modules=skin -o     # explicitly activate the
> modules-skin profile
>
> and then:
> mvn site-deploy -D modules=standard -D deploy=local -o                     #
> activate modules-standard and deploy-local profile
> mvn site-deploy -D modules=standard -D deploy=local -D site=full -o  #
> activate modules-standard,deploy-local, site-full
>
>
> ~~~~
> All the above is also documented in trunk/pom.xml, which I've just this
> minute committed (rev 1030591).
>
> Thx
> Dan
>
>



-- 
Thanks
- Mohammad Nour
  Author of (WebSphere Application Server Community Edition 2.0 User Guide)
  http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

"Stay hungry, stay foolish."
- Steve Jobs