1:16 p.m.
The mavenized thirdparty builds have been running ok (similar testsuite results
to non-maven build) on hudson for a few days and I've heard from other people
that have successfully run the build locally.
So I'm planning to switch to the mavenized thirdparty build at the end of the
day today. Please try it out if you haven't already (ant -f build-maven.xml),
and bring up any issues.
There are still some issues that we are working out regarding managing the
dependencies (see build forum for more info), but these issues don't prevent
building and testing, and I believe they can be resolved as development continues.
6:19 p.m.
Paul Gier wrote:
The mavenized thirdparty builds have been running ok (similar
testsuite
results to non-maven build) on hudson for a few days and I've heard from
other people that have successfully run the build locally.
So I'm planning to switch to the mavenized thirdparty build at the end
of the day today. Please try it out if you haven't already (ant -f
build-maven.xml), and bring up any issues.
There are still some issues that we are working out regarding managing
the dependencies (see build forum for more info), but these issues don't
prevent building and testing, and I believe they can be resolved as
development continues.
I have switched build.xml to use the maven generated thirdparty directory. The
build is run the same way that it was before (i.e. build.sh).
You may want to check your maven settings to make sure that you have your
settings.xml set up correctly if you are having problems building.
http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenSettings
8:45 p.m.
I checked out a fresh copy of trunk and both the server and testsuite
build are working.
Paul Gier wrote:
Paul Gier wrote:
> The mavenized thirdparty builds have been running ok (similar
> testsuite results to non-maven build) on hudson for a few days and
> I've heard from other people that have successfully run the build
> locally.
>
> So I'm planning to switch to the mavenized thirdparty build at the
> end of the day today. Please try it out if you haven't already (ant
> -f build-maven.xml), and bring up any issues.
>
> There are still some issues that we are working out regarding
> managing the dependencies (see build forum for more info), but these
> issues don't prevent building and testing, and I believe they can be
> resolved as development continues.
I have switched build.xml to use the maven generated thirdparty
directory. The build is run the same way that it was before (i.e.
build.sh).
You may want to check your maven settings to make sure that you have
your settings.xml set up correctly if you are having problems building.
http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenSettings
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:32 a.m.
Paul Gier wrote:
The mavenized thirdparty builds have been running ok (similar
testsuite
results to non-maven build) on hudson for a few days and I've heard from
other people that have successfully run the build locally.
So I'm planning to switch to the mavenized thirdparty build at the end
of the day today. Please try it out if you haven't already (ant -f
build-maven.xml), and bring up any issues.
There are still some issues that we are working out regarding managing
the dependencies (see build forum for more info), but these issues don't
prevent building and testing, and I believe they can be resolved as
development continues.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
It keeps going despite of a missing dependency (local workspace change).
Carlo
====8<====
[carlo@nymph build]$ ./build.sh clean main
Searching for build.xml ...
Buildfile: /home/carlo/work/jboss-head/build/build.xml
check.inhibit.downloads:
check.proxy:
set.proxy.withoutauth:
set.proxy.auth:
set.proxy:
createthirdparty:
[java] [INFO] Scanning for projects...
[java] [INFO]
------------------------------------------------------------------------
[java] [ERROR] FATAL ERROR
[java] [INFO]
------------------------------------------------------------------------
[java] [INFO] Error building POM (may not be this project's POM).
[java] Project ID: org.jboss.jbossas:jboss-as-thirdparty
[java] POM Location: /home/carlo/work/jboss-head/thirdparty/pom.xml
[java] Validation Messages:
[java] [0] 'dependencies.dependency.version' is missing for
org.jboss.ejb3:jboss-ejb3-impl
[java] Reason: Failed to validate POM for project
org.jboss.jbossas:jboss-as-thirdparty at
/home/carlo/work/jboss-head/thirdparty/pom.xml
[java] [INFO]
------------------------------------------------------------------------
[java] [INFO] Trace
[java] org.apache.maven.reactor.MavenExecutionException: Failed to
validate POM for project org.jboss.jbossas:jboss-as-thirdparty at
/home/carlo/work/jboss-head/thirdparty/pom.xml
[java] at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
[java] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
[java] at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
[java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[java] at
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[java] at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[java] at
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[java] Caused by:
org.apache.maven.project.InvalidProjectModelException: Failed to
validate POM for project org.jboss.jbossas:jboss-as-thirdparty at
/home/carlo/work/jboss-head/thirdparty/pom.xml
[java] at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:996)
[java] at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:799)
[java] at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476)
[java] at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
[java] at
org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
[java] at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
[java] at
org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
[java] ... 11 more
[java] [INFO]
------------------------------------------------------------------------
[java] [INFO] Total time: 1 second
[java] [INFO] Finished at: Thu Apr 03 11:29:01 CEST 2008
[java] [INFO] Final Memory: 3M/64M
[java] [INFO]
------------------------------------------------------------------------
[java] Java Result: 1
_buildmagic:init:
Trying to override old definition of task property
_buildmagic:init:local-properties:
_buildmagic:init:buildlog:
configure:
[echo] groups: default
[echo] modules:
main,bootstrap,j2se,mbeans,jmx,system,system-jmx,security,server,deployment,jbossas/remoting,jmx-remoting,jbossas/jmx-remoting,messaging,jbossmq,cluster,varia,iiop,aspects,profileservice,connector,management,ejb3,tomcat,webservices,hibernate-int,console,spring-int
init:
_buildmagic:clean:
_buildmagic:clean-internal:
1:22 a.m.
One difference is that the source artifacts are not being downloaded any
longer. We should be able to define which sources are downloaded by
default in the mapping section via an includeSources or some such element:
<dependency>
<groupId>org.jboss.cl</groupId>
<artifactId>jboss-classloader</artifactId>
<mapping>
<componentId>jboss.jboss-cl</componentId>
<includeSources>true</includeSources>
</mapping>
</dependency>
Would that be easy to add?
I can run mvn dependency:sources from thirdparty to pull all of the
source dependencies into my local maven tree, but this does not update
thirdparty.
Paul Gier wrote:
The mavenized thirdparty builds have been running ok (similar
testsuite results to non-maven build) on hudson for a few days and
I've heard from other people that have successfully run the build
locally.
So I'm planning to switch to the mavenized thirdparty build at the end
of the day today. Please try it out if you haven't already (ant -f
build-maven.xml), and bring up any issues.
There are still some issues that we are working out regarding managing
the dependencies (see build forum for more info), but these issues
don't prevent building and testing, and I believe they can be resolved
as development continues.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
9:03 a.m.
I could add it to the mapping like that, but it would not download the sources
for the non-mapped artifacts. I'll try to make the plugin automatically check
for sources and download them if they exists. Does the zip vs. jar format matter?
Scott Stark wrote:
One difference is that the source artifacts are not being downloaded
any
longer. We should be able to define which sources are downloaded by
default in the mapping section via an includeSources or some such element:
<dependency>
<groupId>org.jboss.cl</groupId>
<artifactId>jboss-classloader</artifactId>
<mapping>
<componentId>jboss.jboss-cl</componentId>
<includeSources>true</includeSources>
</mapping>
</dependency>
Would that be easy to add?
I can run mvn dependency:sources from thirdparty to pull all of the
source dependencies into my local maven tree, but this does not update
thirdparty.
Paul Gier wrote:
> The mavenized thirdparty builds have been running ok (similar
> testsuite results to non-maven build) on hudson for a few days and
> I've heard from other people that have successfully run the build
> locally.
>
> So I'm planning to switch to the mavenized thirdparty build at the end
> of the day today. Please try it out if you haven't already (ant -f
> build-maven.xml), and bring up any issues.
>
> There are still some issues that we are working out regarding managing
> the dependencies (see build forum for more info), but these issues
> don't prevent building and testing, and I believe they can be resolved
> as development continues.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
9:26 a.m.
The zip vs jar does not matter. Its the eclipse classpath that
references the source artifact. I expect where the zip style is used,
the name of the source artifact would be incorrect coming from maven,
but its probably easier to update the .classpath for those cases.
Paul Gier wrote:
I could add it to the mapping like that, but it would not download
the
sources for the non-mapped artifacts. I'll try to make the plugin
automatically check for sources and download them if they exists.
Does the zip vs. jar format matter?
6:55 a.m.
How are transitive dependencies handled in the thirdparty build? Carlo
says the jboss-ejb3-interceptors should be coming in as a transitive
dependency of jboss-ejb3-core rather than specified in the
jbossas/component-matrix/pom.xml as is done now:
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-interceptors</artifactId>
<version>0.12.0</version>
<exclusions>
<exclusion>
<groupId>org.jboss</groupId>
<artifactId>jboss-metadata</artifactId>
</exclusion>
</exclusions>
</dependency>
9:01 a.m.
If you remove the dependency that should work fine. The thirdparty build will
still pick it up as a transitive dependency. Just make sure you leave the
dependency mapping plugin configuration there so that the jars go to the right
place.
Scott Stark wrote:
How are transitive dependencies handled in the thirdparty build?
Carlo
says the jboss-ejb3-interceptors should be coming in as a transitive
dependency of jboss-ejb3-core rather than specified in the
jbossas/component-matrix/pom.xml as is done now:
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-interceptors</artifactId>
<version>0.12.0</version>
<exclusions>
<exclusion>
<groupId>org.jboss</groupId>
<artifactId>jboss-metadata</artifactId>
</exclusion>
</exclusions>
</dependency>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:10 p.m.
I just wanted to follow up on this issue of including the source jars.
Yesterday I added a profile to the maven thirdparty build that will download
source jars (using the maven dependency plugin) to the local maven repo. The
maven plugin will then look for the source jars in the local maven repository
and copy them to the correct location in the thirdparty folder.
Currently this is off by default because checking for the sources can be time
consuming, and they only need to be downloaded on the first build.
I also added the ability to pass maven options to the thirdparty build through
build.sh or build.xml. So for example to call the profile for downloading
sources, the command looks like this:
./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
This causes the following command to be run against the thirdparty/pom.xml
mvn -Pdownload-sources package
So any maven options that you want to pass to the mavenized thirdparty can be
passed through that property.
Paul Gier wrote:
I could add it to the mapping like that, but it would not download
the
sources for the non-mapped artifacts. I'll try to make the plugin
automatically check for sources and download them if they exists. Does
the zip vs. jar format matter?
Scott Stark wrote:
> One difference is that the source artifacts are not being downloaded
> any longer. We should be able to define which sources are downloaded
> by default in the mapping section via an includeSources or some such
> element:
>
> <dependency>
> <groupId>org.jboss.cl</groupId>
> <artifactId>jboss-classloader</artifactId>
> <mapping>
> <componentId>jboss.jboss-cl</componentId>
> <includeSources>true</includeSources>
> </mapping>
> </dependency>
>
> Would that be easy to add?
>
> I can run mvn dependency:sources from thirdparty to pull all of the
> source dependencies into my local maven tree, but this does not update
> thirdparty.
>
> Paul Gier wrote:
>> The mavenized thirdparty builds have been running ok (similar
>> testsuite results to non-maven build) on hudson for a few days and
>> I've heard from other people that have successfully run the build
>> locally.
>>
>> So I'm planning to switch to the mavenized thirdparty build at the
>> end of the day today. Please try it out if you haven't already (ant
>> -f build-maven.xml), and bring up any issues.
>>
>> There are still some issues that we are working out regarding
>> managing the dependencies (see build forum for more info), but these
>> issues don't prevent building and testing, and I believe they can be
>> resolved as development continues.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
8:53 a.m.
Looks good in my usage so far.
Paul Gier wrote:
I just wanted to follow up on this issue of including the source
jars.
Yesterday I added a profile to the maven thirdparty build that will
download source jars (using the maven dependency plugin) to the local
maven repo. The maven plugin will then look for the source jars in
the local maven repository and copy them to the correct location in
the thirdparty folder.
Currently this is off by default because checking for the sources can
be time consuming, and they only need to be downloaded on the first
build.
I also added the ability to pass maven options to the thirdparty build
through build.sh or build.xml. So for example to call the profile for
downloading sources, the command looks like this:
./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
This causes the following command to be run against the
thirdparty/pom.xml
mvn -Pdownload-sources package
So any maven options that you want to pass to the mavenized thirdparty
can be passed through that property.
10:50 a.m.
What can I pass to build.sh to stop it updating my thirdparty?
I just did a build following a 2 line change to a class, and suddenly
the AS wouldn't start cleanly anymore because some new version of a
snapshot got downloaded.
Paul Gier wrote:
I just wanted to follow up on this issue of including the source
jars.
Yesterday I added a profile to the maven thirdparty build that will
download source jars (using the maven dependency plugin) to the local
maven repo. The maven plugin will then look for the source jars in the
local maven repository and copy them to the correct location in the
thirdparty folder.
Currently this is off by default because checking for the sources can be
time consuming, and they only need to be downloaded on the first build.
I also added the ability to pass maven options to the thirdparty build
through build.sh or build.xml. So for example to call the profile for
downloading sources, the command looks like this:
./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
This causes the following command to be run against the thirdparty/pom.xml
mvn -Pdownload-sources package
So any maven options that you want to pass to the mavenized thirdparty
can be passed through that property.
Paul Gier wrote:
> I could add it to the mapping like that, but it would not download the
> sources for the non-mapped artifacts. I'll try to make the plugin
> automatically check for sources and download them if they exists.
> Does the zip vs. jar format matter?
>
> Scott Stark wrote:
>> One difference is that the source artifacts are not being downloaded
>> any longer. We should be able to define which sources are downloaded
>> by default in the mapping section via an includeSources or some such
>> element:
>>
>> <dependency>
>> <groupId>org.jboss.cl</groupId>
>> <artifactId>jboss-classloader</artifactId>
>> <mapping>
>> <componentId>jboss.jboss-cl</componentId>
>> <includeSources>true</includeSources>
>> </mapping>
>> </dependency>
>>
>> Would that be easy to add?
>>
>> I can run mvn dependency:sources from thirdparty to pull all of the
>> source dependencies into my local maven tree, but this does not
>> update thirdparty.
>>
>> Paul Gier wrote:
>>> The mavenized thirdparty builds have been running ok (similar
>>> testsuite results to non-maven build) on hudson for a few days and
>>> I've heard from other people that have successfully run the build
>>> locally.
>>>
>>> So I'm planning to switch to the mavenized thirdparty build at the
>>> end of the day today. Please try it out if you haven't already (ant
>>> -f build-maven.xml), and bring up any issues.
>>>
>>> There are still some issues that we are working out regarding
>>> managing the dependencies (see build forum for more info), but these
>>> issues don't prevent building and testing, and I believe they can be
>>> resolved as development continues.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
11 a.m.
Adding -Dinhibit.downloads=true or adding this to the local.properties
file in build should work.
Brian Stansberry wrote:
What can I pass to build.sh to stop it updating my thirdparty?
I just did a build following a 2 line change to a class, and suddenly
the AS wouldn't start cleanly anymore because some new version of a
snapshot got downloaded.
11:03 a.m.
Brian Stansberry wrote:
What can I pass to build.sh to stop it updating my thirdparty?
Go into your ~/.m2/settings.xml and set the snapshot policy to "never"
on the snapshots repo. The default is once daily. Then you can have
manual control of when the snapshots are updated by passing the "-U"
switch to mvn.
I just did a build following a 2 line change to a class, and suddenly
the AS wouldn't start cleanly anymore because some new version of a
snapshot got downloaded.
This is the evil of snapshots. We've got to be depending upon frequent
releases, using snapshots at a minimum when developing locally. Then
release, then do integration testing.
Paul Gier wrote:
> I just wanted to follow up on this issue of including the source jars.
> Yesterday I added a profile to the maven thirdparty build that will
> download source jars (using the maven dependency plugin) to the local
> maven repo. The maven plugin will then look for the source jars in
> the local maven repository and copy them to the correct location in
> the thirdparty folder.
>
> Currently this is off by default because checking for the sources can
> be time consuming, and they only need to be downloaded on the first
> build.
>
> I also added the ability to pass maven options to the thirdparty build
> through build.sh or build.xml. So for example to call the profile for
> downloading sources, the command looks like this:
>
> ./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
>
> This causes the following command to be run against the
> thirdparty/pom.xml
>
> mvn -Pdownload-sources package
>
> So any maven options that you want to pass to the mavenized thirdparty
> can be passed through that property.
>
>
> Paul Gier wrote:
>> I could add it to the mapping like that, but it would not download
>> the sources for the non-mapped artifacts. I'll try to make the
>> plugin automatically check for sources and download them if they
>> exists. Does the zip vs. jar format matter?
>>
>> Scott Stark wrote:
>>> One difference is that the source artifacts are not being downloaded
>>> any longer. We should be able to define which sources are downloaded
>>> by default in the mapping section via an includeSources or some such
>>> element:
>>>
>>> <dependency>
>>> <groupId>org.jboss.cl</groupId>
>>> <artifactId>jboss-classloader</artifactId>
>>> <mapping>
>>> <componentId>jboss.jboss-cl</componentId>
>>> <includeSources>true</includeSources>
>>> </mapping>
>>> </dependency>
>>>
>>> Would that be easy to add?
>>>
>>> I can run mvn dependency:sources from thirdparty to pull all of the
>>> source dependencies into my local maven tree, but this does not
>>> update thirdparty.
>>>
>>> Paul Gier wrote:
>>>> The mavenized thirdparty builds have been running ok (similar
>>>> testsuite results to non-maven build) on hudson for a few days and
>>>> I've heard from other people that have successfully run the build
>>>> locally.
>>>>
>>>> So I'm planning to switch to the mavenized thirdparty build at the
>>>> end of the day today. Please try it out if you haven't already
>>>> (ant -f build-maven.xml), and bring up any issues.
>>>>
>>>> There are still some issues that we are working out regarding
>>>> managing the dependencies (see build forum for more info), but
>>>> these issues don't prevent building and testing, and I believe they
>>>> can be resolved as development continues.
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com
11:06 a.m.
On Wed, 2008-04-16 at 10:50 -0500, Brian Stansberry wrote:
What can I pass to build.sh to stop it updating my thirdparty?
I just did a build following a 2 line change to a class, and suddenly
the AS wouldn't start cleanly anymore because some new version of a
snapshot got downloaded.
The same as the previous build:
-Dinhibit.downloads=true
The difference is that maven looks for changed snapshots once a
day while the old build only looked when build-thirdparty.xml changed.
I guess we could add a check on whether component-martix/pom.xml
is newer than thirdparty/libraries.ent to reproduce the old
behaviour.
But I actually prefer getting changed snapshots instead of broken builds
due to snapshots not updating.
Of course, if the snapshot is broken, that's another matter. ;-)
Paul Gier wrote:
> I just wanted to follow up on this issue of including the source jars.
> Yesterday I added a profile to the maven thirdparty build that will
> download source jars (using the maven dependency plugin) to the local
> maven repo. The maven plugin will then look for the source jars in the
> local maven repository and copy them to the correct location in the
> thirdparty folder.
>
> Currently this is off by default because checking for the sources can be
> time consuming, and they only need to be downloaded on the first build.
>
> I also added the ability to pass maven options to the thirdparty build
> through build.sh or build.xml. So for example to call the profile for
> downloading sources, the command looks like this:
>
> ./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
>
> This causes the following command to be run against the thirdparty/pom.xml
>
> mvn -Pdownload-sources package
>
> So any maven options that you want to pass to the mavenized thirdparty
> can be passed through that property.
>
>
> Paul Gier wrote:
>> I could add it to the mapping like that, but it would not download the
>> sources for the non-mapped artifacts. I'll try to make the plugin
>> automatically check for sources and download them if they exists.
>> Does the zip vs. jar format matter?
>>
>> Scott Stark wrote:
>>> One difference is that the source artifacts are not being downloaded
>>> any longer. We should be able to define which sources are downloaded
>>> by default in the mapping section via an includeSources or some such
>>> element:
>>>
>>> <dependency>
>>> <groupId>org.jboss.cl</groupId>
>>> <artifactId>jboss-classloader</artifactId>
>>> <mapping>
>>> <componentId>jboss.jboss-cl</componentId>
>>> <includeSources>true</includeSources>
>>> </mapping>
>>> </dependency>
>>>
>>> Would that be easy to add?
>>>
>>> I can run mvn dependency:sources from thirdparty to pull all of the
>>> source dependencies into my local maven tree, but this does not
>>> update thirdparty.
>>>
>>> Paul Gier wrote:
>>>> The mavenized thirdparty builds have been running ok (similar
>>>> testsuite results to non-maven build) on hudson for a few days and
>>>> I've heard from other people that have successfully run the build
>>>> locally.
>>>>
>>>> So I'm planning to switch to the mavenized thirdparty build at the
>>>> end of the day today. Please try it out if you haven't already (ant
>>>> -f build-maven.xml), and bring up any issues.
>>>>
>>>> There are still some issues that we are working out regarding
>>>> managing the dependencies (see build forum for more info), but these
>>>> issues don't prevent building and testing, and I believe they can be
>>>> resolved as development continues.
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:23 a.m.
Adrian Brock wrote:
On Wed, 2008-04-16 at 10:50 -0500, Brian Stansberry wrote:
> What can I pass to build.sh to stop it updating my thirdparty?
>
> I just did a build following a 2 line change to a class, and suddenly
> the AS wouldn't start cleanly anymore because some new version of a
> snapshot got downloaded.
>
The same as the previous build:
-Dinhibit.downloads=true
Which I also never knew. :-(
The difference is that maven looks for changed snapshots once a
day while the old build only looked when build-thirdparty.xml changed.
I guess we could add a check on whether component-martix/pom.xml
is newer than thirdparty/libraries.ent to reproduce the old
behaviour.
But I actually prefer getting changed snapshots instead of broken builds
due to snapshots not updating.
Me too. Most of the time. As long as I know how to control it, I'm
happy. :-)
Of course, if the snapshot is broken, that's another matter. ;-)
Nah, that will never happen. ;-)
Thanks, all, for the quick responses.
> Paul Gier wrote:
>> I just wanted to follow up on this issue of including the source jars.
>> Yesterday I added a profile to the maven thirdparty build that will
>> download source jars (using the maven dependency plugin) to the local
>> maven repo. The maven plugin will then look for the source jars in the
>> local maven repository and copy them to the correct location in the
>> thirdparty folder.
>>
>> Currently this is off by default because checking for the sources can be
>> time consuming, and they only need to be downloaded on the first build.
>>
>> I also added the ability to pass maven options to the thirdparty build
>> through build.sh or build.xml. So for example to call the profile for
>> downloading sources, the command looks like this:
>>
>> ./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
>>
>> This causes the following command to be run against the thirdparty/pom.xml
>>
>> mvn -Pdownload-sources package
>>
>> So any maven options that you want to pass to the mavenized thirdparty
>> can be passed through that property.
>>
>>
>> Paul Gier wrote:
>>> I could add it to the mapping like that, but it would not download the
>>> sources for the non-mapped artifacts. I'll try to make the plugin
>>> automatically check for sources and download them if they exists.
>>> Does the zip vs. jar format matter?
>>>
>>> Scott Stark wrote:
>>>> One difference is that the source artifacts are not being downloaded
>>>> any longer. We should be able to define which sources are downloaded
>>>> by default in the mapping section via an includeSources or some such
>>>> element:
>>>>
>>>> <dependency>
>>>> <groupId>org.jboss.cl</groupId>
>>>> <artifactId>jboss-classloader</artifactId>
>>>> <mapping>
>>>> <componentId>jboss.jboss-cl</componentId>
>>>> <includeSources>true</includeSources>
>>>> </mapping>
>>>> </dependency>
>>>>
>>>> Would that be easy to add?
>>>>
>>>> I can run mvn dependency:sources from thirdparty to pull all of the
>>>> source dependencies into my local maven tree, but this does not
>>>> update thirdparty.
>>>>
>>>> Paul Gier wrote:
>>>>> The mavenized thirdparty builds have been running ok (similar
>>>>> testsuite results to non-maven build) on hudson for a few days and
>>>>> I've heard from other people that have successfully run the build
>>>>> locally.
>>>>>
>>>>> So I'm planning to switch to the mavenized thirdparty build at
the
>>>>> end of the day today. Please try it out if you haven't already
(ant
>>>>> -f build-maven.xml), and bring up any issues.
>>>>>
>>>>> There are still some issues that we are working out regarding
>>>>> managing the dependencies (see build forum for more info), but these
>>>>> issues don't prevent building and testing, and I believe they can
be
>>>>> resolved as development continues.
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
4:47 a.m.
Can a wiki page be created with this stuff, if there is not one already?
Paul Gier wrote:
I just wanted to follow up on this issue of including the source
jars.
Yesterday I added a profile to the maven thirdparty build that will
download source jars (using the maven dependency plugin) to the local
maven repo. The maven plugin will then look for the source jars in the
local maven repository and copy them to the correct location in the
thirdparty folder.
Currently this is off by default because checking for the sources can be
time consuming, and they only need to be downloaded on the first build.
I also added the ability to pass maven options to the thirdparty build
through build.sh or build.xml. So for example to call the profile for
downloading sources, the command looks like this:
./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
This causes the following command to be run against the thirdparty/pom.xml
mvn -Pdownload-sources package
So any maven options that you want to pass to the mavenized thirdparty
can be passed through that property.
Paul Gier wrote:
> I could add it to the mapping like that, but it would not download the
> sources for the non-mapped artifacts. I'll try to make the plugin
> automatically check for sources and download them if they exists.
> Does the zip vs. jar format matter?
>
> Scott Stark wrote:
>> One difference is that the source artifacts are not being downloaded
>> any longer. We should be able to define which sources are downloaded
>> by default in the mapping section via an includeSources or some such
>> element:
>>
>> <dependency>
>> <groupId>org.jboss.cl</groupId>
>> <artifactId>jboss-classloader</artifactId>
>> <mapping>
>> <componentId>jboss.jboss-cl</componentId>
>> <includeSources>true</includeSources>
>> </mapping>
>> </dependency>
>>
>> Would that be easy to add?
>>
>> I can run mvn dependency:sources from thirdparty to pull all of the
>> source dependencies into my local maven tree, but this does not
>> update thirdparty.
>>
>> Paul Gier wrote:
>>> The mavenized thirdparty builds have been running ok (similar
>>> testsuite results to non-maven build) on hudson for a few days and
>>> I've heard from other people that have successfully run the build
>>> locally.
>>>
>>> So I'm planning to switch to the mavenized thirdparty build at the
>>> end of the day today. Please try it out if you haven't already (ant
>>> -f build-maven.xml), and bring up any issues.
>>>
>>> There are still some issues that we are working out regarding
>>> managing the dependencies (see build forum for more info), but these
>>> issues don't prevent building and testing, and I believe they can be
>>> resolved as development continues.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
4:48 a.m.
Ooops
http://wiki.jboss.org/wiki/MavenBuildmagicThirdpartyPlugin
Kabir Khan wrote:
Can a wiki page be created with this stuff, if there is not one
already?
Paul Gier wrote:
> I just wanted to follow up on this issue of including the source jars.
> Yesterday I added a profile to the maven thirdparty build that will
> download source jars (using the maven dependency plugin) to the local
> maven repo. The maven plugin will then look for the source jars in
> the local maven repository and copy them to the correct location in
> the thirdparty folder.
>
> Currently this is off by default because checking for the sources can
> be time consuming, and they only need to be downloaded on the first
> build.
>
> I also added the ability to pass maven options to the thirdparty build
> through build.sh or build.xml. So for example to call the profile for
> downloading sources, the command looks like this:
>
> ./build.sh -Dthirdparty.maven.opts="-Pdownload-sources"
>
> This causes the following command to be run against the
> thirdparty/pom.xml
>
> mvn -Pdownload-sources package
>
> So any maven options that you want to pass to the mavenized thirdparty
> can be passed through that property.
>
>
> Paul Gier wrote:
>> I could add it to the mapping like that, but it would not download
>> the sources for the non-mapped artifacts. I'll try to make the
>> plugin automatically check for sources and download them if they
>> exists. Does the zip vs. jar format matter?
>>
>> Scott Stark wrote:
>>> One difference is that the source artifacts are not being downloaded
>>> any longer. We should be able to define which sources are downloaded
>>> by default in the mapping section via an includeSources or some such
>>> element:
>>>
>>> <dependency>
>>> <groupId>org.jboss.cl</groupId>
>>> <artifactId>jboss-classloader</artifactId>
>>> <mapping>
>>> <componentId>jboss.jboss-cl</componentId>
>>> <includeSources>true</includeSources>
>>> </mapping>
>>> </dependency>
>>>
>>> Would that be easy to add?
>>>
>>> I can run mvn dependency:sources from thirdparty to pull all of the
>>> source dependencies into my local maven tree, but this does not
>>> update thirdparty.
>>>
>>> Paul Gier wrote:
>>>> The mavenized thirdparty builds have been running ok (similar
>>>> testsuite results to non-maven build) on hudson for a few days and
>>>> I've heard from other people that have successfully run the build
>>>> locally.
>>>>
>>>> So I'm planning to switch to the mavenized thirdparty build at the
>>>> end of the day today. Please try it out if you haven't already
>>>> (ant -f build-maven.xml), and bring up any issues.
>>>>
>>>> There are still some issues that we are working out regarding
>>>> managing the dependencies (see build forum for more info), but
>>>> these issues don't prevent building and testing, and I believe they
>>>> can be resolved as development continues.
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
5878
days inactive
5894
days old
jboss-development@lists.jboss.org
17 comments
7 participants
participants (7)
-
Adrian Brock -
Andrew Lee Rubinger -
Brian Stansberry -
Carlo de Wolf -
Kabir Khan -
Paul Gier -
Scott Stark